libvirt/src/admin_protocol-structs

172 lines
5.6 KiB
Plaintext
Raw Normal View History

/* -*- c -*- */
struct admin_typed_param_value {
int type;
union {
int i;
u_int ui;
int64_t l;
uint64_t ul;
double d;
int b;
admin_nonnull_string s;
} admin_typed_param_value_u;
};
struct admin_typed_param {
admin_nonnull_string field;
admin_typed_param_value value;
};
struct admin_nonnull_server {
admin_nonnull_string name;
};
struct admin_nonnull_client {
admin_nonnull_server srv;
uint64_t id;
int64_t timestamp;
u_int transport;
};
struct admin_connect_open_args {
u_int flags;
};
struct admin_connect_get_lib_version_ret {
uint64_t libVer;
};
struct admin_connect_list_servers_args {
u_int need_results;
u_int flags;
};
struct admin_connect_list_servers_ret {
struct {
u_int servers_len;
admin_nonnull_server * servers_val;
} servers;
u_int ret;
};
struct admin_connect_lookup_server_args {
admin_nonnull_string name;
u_int flags;
};
struct admin_connect_lookup_server_ret {
admin_nonnull_server srv;
};
struct admin_server_get_threadpool_parameters_args {
admin_nonnull_server srv;
u_int flags;
};
struct admin_server_get_threadpool_parameters_ret {
struct {
u_int params_len;
admin_typed_param * params_val;
} params;
};
admin: Introduce virAdmServerSetThreadPoolParameters Since threadpool increments the current number of threads according to current load, i.e. how many jobs are waiting in the queue. The count however, is constrained by max and min limits of workers. The logic of this new API works like this: 1) setting the minimum a) When the limit is increased, depending on the current number of threads, new threads are possibly spawned if the current number of threads is less than the new minimum limit b) Decreasing the minimum limit has no possible effect on the current number of threads 2) setting the maximum a) Icreasing the maximum limit has no immediate effect on the current number of threads, it only allows the threadpool to spawn more threads when new jobs, that would otherwise end up queued, arrive. b) Decreasing the maximum limit may affect the current number of threads, if the current number of threads is less than the new maximum limit. Since there may be some ongoing time-consuming jobs that would effectively block this API from killing any threads. Therefore, this API is asynchronous with best-effort execution, i.e. the necessary number of workers will be terminated once they finish their previous job, unless other workers had already terminated, decreasing the limit to the requested value. 3) setting priority workers - both increase and decrease in count of these workers have an immediate impact on the current number of workers, new ones will be spawned or some of them get terminated respectively. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-02-22 13:24:04 +00:00
struct admin_server_set_threadpool_parameters_args {
admin_nonnull_server srv;
struct {
u_int params_len;
admin_typed_param * params_val;
} params;
u_int flags;
};
struct admin_server_list_clients_args {
admin_nonnull_server srv;
u_int need_results;
u_int flags;
};
struct admin_server_list_clients_ret {
struct {
u_int clients_len;
admin_nonnull_client * clients_val;
} clients;
u_int ret;
};
struct admin_server_lookup_client_args {
admin_nonnull_server srv;
uint64_t id;
u_int flags;
};
struct admin_server_lookup_client_ret {
admin_nonnull_client clnt;
};
struct admin_client_get_info_args {
admin_nonnull_client clnt;
u_int flags;
};
struct admin_client_get_info_ret {
struct {
u_int params_len;
admin_typed_param * params_val;
} params;
};
struct admin_client_close_args {
admin_nonnull_client clnt;
u_int flags;
};
struct admin_server_get_client_limits_args {
admin_nonnull_server srv;
u_int flags;
};
struct admin_server_get_client_limits_ret {
struct {
u_int params_len;
admin_typed_param * params_val;
} params;
};
struct admin_server_set_client_limits_args {
admin_nonnull_server srv;
struct {
u_int params_len;
admin_typed_param * params_val;
} params;
u_int flags;
};
struct admin_server_update_tls_files_args {
admin_nonnull_server srv;
u_int flags;
};
struct admin_connect_get_logging_outputs_args {
u_int flags;
};
struct admin_connect_get_logging_outputs_ret {
admin_nonnull_string outputs;
u_int noutputs;
};
struct admin_connect_get_logging_filters_args {
u_int flags;
};
struct admin_connect_get_logging_filters_ret {
admin_string filters;
u_int nfilters;
};
struct admin_connect_set_logging_outputs_args {
admin_string outputs;
u_int flags;
};
struct admin_connect_set_logging_filters_args {
admin_string filters;
u_int flags;
};
struct admin_connect_set_daemon_timeout_args {
u_int timeout;
u_int flags;
};
enum admin_procedure {
ADMIN_PROC_CONNECT_OPEN = 1,
ADMIN_PROC_CONNECT_CLOSE = 2,
ADMIN_PROC_CONNECT_GET_LIB_VERSION = 3,
ADMIN_PROC_CONNECT_LIST_SERVERS = 4,
ADMIN_PROC_CONNECT_LOOKUP_SERVER = 5,
ADMIN_PROC_SERVER_GET_THREADPOOL_PARAMETERS = 6,
admin: Introduce virAdmServerSetThreadPoolParameters Since threadpool increments the current number of threads according to current load, i.e. how many jobs are waiting in the queue. The count however, is constrained by max and min limits of workers. The logic of this new API works like this: 1) setting the minimum a) When the limit is increased, depending on the current number of threads, new threads are possibly spawned if the current number of threads is less than the new minimum limit b) Decreasing the minimum limit has no possible effect on the current number of threads 2) setting the maximum a) Icreasing the maximum limit has no immediate effect on the current number of threads, it only allows the threadpool to spawn more threads when new jobs, that would otherwise end up queued, arrive. b) Decreasing the maximum limit may affect the current number of threads, if the current number of threads is less than the new maximum limit. Since there may be some ongoing time-consuming jobs that would effectively block this API from killing any threads. Therefore, this API is asynchronous with best-effort execution, i.e. the necessary number of workers will be terminated once they finish their previous job, unless other workers had already terminated, decreasing the limit to the requested value. 3) setting priority workers - both increase and decrease in count of these workers have an immediate impact on the current number of workers, new ones will be spawned or some of them get terminated respectively. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-02-22 13:24:04 +00:00
ADMIN_PROC_SERVER_SET_THREADPOOL_PARAMETERS = 7,
ADMIN_PROC_SERVER_LIST_CLIENTS = 8,
ADMIN_PROC_SERVER_LOOKUP_CLIENT = 9,
ADMIN_PROC_CLIENT_GET_INFO = 10,
ADMIN_PROC_CLIENT_CLOSE = 11,
ADMIN_PROC_SERVER_GET_CLIENT_LIMITS = 12,
ADMIN_PROC_SERVER_SET_CLIENT_LIMITS = 13,
ADMIN_PROC_CONNECT_GET_LOGGING_OUTPUTS = 14,
ADMIN_PROC_CONNECT_GET_LOGGING_FILTERS = 15,
ADMIN_PROC_CONNECT_SET_LOGGING_OUTPUTS = 16,
ADMIN_PROC_CONNECT_SET_LOGGING_FILTERS = 17,
ADMIN_PROC_SERVER_UPDATE_TLS_FILES = 18,
ADMIN_PROC_CONNECT_SET_DAEMON_TIMEOUT = 19,
};