add json power policy interface for containers
cover add json power policy interface for containers
The current vm_power_manager example app has the capability to accept power policies from virtual machines via virtio-serial channels. These power policies allow a virtual machine to give information to the power manager to allow the power manager take care of the power management of the virtual machine based on the information in the policy.
This power policy functionality is limited to virtual machines sending the policies to the power manager (which runs in the Host OS), and a solution was needed for additional methods of sending power policies to the power manager app.
The main use-case for this modification is for containers and host applications that wish to send polices to the power manager.
This patchset adds the capability to send power polices and power commands to the vm_power_manager app via JSON strings through a fifo on the file system.
For example, given the following file, policy.json:
{"policy": {
"name": "ubuntu2",
"command": "create",
"policy_type": "TIME",
"busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ],
"quiet_hours":[ 2, 3, 4, 5, 6 ],
"core_list":[ 11, 12, 13 ]
}}
Then running the command:
cat policy.json >/tmp/powermonitor/fifo.0
The policy is sent to the vm_power_manager. The power manager app then parses the JSON data, and inserts the policy into the array of policies.
Part of the patch series contains documentation updates to give all the details of the valid name-value pairs, the data types, etc.
[1/7] examples/power: add checks around hypervisor [2/7] lib/power: add changes for host commands/policies [3/7] examples/power: add necessary changes to guest app [4/7] examples/power: add host channel to power manager [5/7] examples/power: add json string handling [6/7] doc/vm_power_manager: add JSON interface API info [7/7] examples/power: add json example files
PATCH 1/7 examples/power: add checks around hypervisor
Allow vm_power_manager to run without requiring qemy to be present on the machine. This will be required for instances where the JSON interface is used for commands and polices, without any VMs present. A use case for this is a container enviromnent.
--- examples/vm_power_manager/channel_manager.c | 71 +++++++++++++-------- examples/vm_power_manager/channel_monitor.c | 2 +- 2 files changed, 44 insertions(+), 29 deletions(-)
examples/vm_power_manager/channel_manager.c +43 -28
@@ -43,7 +43,8 @@ static unsigned char *global_cpumaps;static virVcpuInfo *global_vircpuinfo;static size_t global_maplen; -static unsigned global_n_host_cpus; +static unsigned int global_n_host_cpus; +static unsigned int global_hypervisor_available;/* * Represents a single Virtual Machine
@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) {struct virtual_machine_info *vm_info = (struct virtual_machine_info *)chan_info->priv_info; -return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); + +if ((global_hypervisor_available) && (vm_info !=NULL )) +return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); +else +return 0 ; } static inline int
@@ -559,6 +564,8 @@ get_all_vm(int *num_vm, int *num_vcpu)VIR_CONNECT_LIST_DOMAINS_PERSISTENT ;unsigned int domain_flag =VIR_DOMAIN_VCPU_CONFIG ; +if (!global_hypervisor_available) +return ;memset (global_cpumaps,0 ,CHANNEL_CMDS_MAX_CPUS *global_maplen);if (virNodeGetInfo (global_vir_conn_ptr, &node_info)) {
@@ -768,38 +775,42 @@ connect_hypervisor(const char *path) }return 0 ; } -int -channel_manager_init (const char *path) +channel_manager_init(const char *path __rte_unused) {virNodeInfo info;LIST_INIT (&vm_list_head);if (connect_hypervisor (path) <0 ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); -return -1 ; - } - - global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + global_n_host_cpus =64 ; + global_hypervisor_available =0 ; +RTE_LOG (INFO ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); + }else { + global_hypervisor_available =1 ; + + global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + + global_vircpuinfo =rte_zmalloc (NULL , +sizeof (*global_vircpuinfo) * +CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); +if (global_vircpuinfo ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); + goto error; + } + global_cpumaps =rte_zmalloc (NULL , +CHANNEL_CMDS_MAX_CPUS * global_maplen, +RTE_CACHE_LINE_SIZE ); +if (global_cpumaps ==NULL ) + goto error; - global_vircpuinfo =rte_zmalloc (NULL ,sizeof (*global_vircpuinfo) * -CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); -if (global_vircpuinfo ==NULL ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); - goto error; - } - global_cpumaps =rte_zmalloc (NULL ,CHANNEL_CMDS_MAX_CPUS * global_maplen, -RTE_CACHE_LINE_SIZE ); -if (global_cpumaps ==NULL ) { - goto error; +if (virNodeGetInfo (global_vir_conn_ptr, &info)) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); + goto error; + } + global_n_host_cpus = (unsigned int )info.cpus; } -if (virNodeGetInfo (global_vir_conn_ptr, &info)) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); - goto error; - } - global_n_host_cpus = (unsigned )info.cpus;if (global_n_host_cpus >CHANNEL_CMDS_MAX_CPUS ) { RTE_LOG(WARNING, CHANNEL_MANAGER, "The number of host CPUs(%u) exceeds the "
@@ -811,7 +822,8 @@ channel_manager_init(const char *path)return 0 ; error: -disconnect_hypervisor (); +if (global_hypervisor_available) +disconnect_hypervisor ();return -1 ; }
@@ -838,7 +850,10 @@ channel_manager_exit(void)rte_free (vm_info); } -rte_free (global_cpumaps); -rte_free (global_vircpuinfo); -disconnect_hypervisor (); +if (global_hypervisor_available) { +/* Only needed if hypervisor available */ +rte_free (global_cpumaps); +rte_free (global_vircpuinfo); +disconnect_hypervisor (); + } }
examples/vm_power_manager/channel_monitor.c +1 -1
@@ -66,7 +66,7 @@ static void core_share_status(int pNo) { -int noVms, noVcpus, z, x, t; +int noVms =0 , noVcpus =0 , z, x, t;get_all_vm (&noVms, &noVcpus);
Signature · 1 line
2.17.1
Re: [PATCH v1 1/7] examples/power: add checks around hypervisor
On Thu, 30 Aug 2018 11:54:16 +0100
David Hunt <[email protected]> wrote:
Minor nits
Quoted 1 line
+static unsigned int
global_hypervisor_available;
Please use bool for boolean values.
examples/vm_power_manager/channel_manager.c get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) · line 203
Quoted 9 lines
/*
* Represents a single Virtual Machineexamples/vm_power_manager/channel_manager.c +2
-1@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) {struct virtual_machine_info *vm_info = (struct virtual_machine_info *)chan_info->priv_info; -return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); + +if ((global_hypervisor_available) && (vm_info !=NULL ))
parenthesis are unnecessary here.
I know this is pre-existing, but please don't use CamelCase:
+ if (virNodeGetInfo(global_vir_conn_ptr, &info)) {
Re: [PATCH v1 1/7] examples/power: add checks around hypervisor
Hi Stephen,
Quoted 7 lines · Stephen Hemminger
On Thu, 30 Aug 2018 11:54:16 +0100
David Hunt <[email protected]> wrote:Minor nits
Quoted 1 line
+static unsigned int
global_hypervisor_available;Please use bool for boolean values.
Will change in next revision.
Quoted 11 lines
examples/vm_power_manager/channel_manager.c get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) · line 203
Quoted 9 lines
/*
* Represents a single Virtual Machineexamples/vm_power_manager/channel_manager.c +2
-1@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) {struct virtual_machine_info *vm_info = (struct virtual_machine_info *)chan_info->priv_info; -return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); + +if ((global_hypervisor_available) && (vm_info !=NULL ))parenthesis are unnecessary here.
Fixed in next version.
examples/vm_power_manager/channel_manager.c connect_hypervisor(const char *path) · line 806
Quoted 4 lines
I know this is pre-existing, but please don't use CamelCase:
examples/vm_power_manager/channel_manager.c +1
-0+if (virNodeGetInfo (global_vir_conn_ptr, &info)) {
Unfortunately I've no control over this, it's part of the libvirt API.
Thanks,
Dave.
PATCH 2/7 lib/power: add changes for host commands/policies
In reply to David Hunt--- lib/librte_power/channel_commands.h | 4 ++++ 1 file changed, 4 insertions(+)
lib/librte_power/channel_commands.h +4 -0
@@ -19,6 +19,7 @@ extern "C" {#define CPU_POWER 1#define CPU_POWER_CONNECT 2#define PKT_POLICY 3 +#define PKT_POLICY_REMOVE 4/* CPU Power Command Scaling */ #define CPU_POWER_SCALE_UP 1
@@ -58,6 +59,8 @@ struct traffic {uint32_t max_max_packet_thresh; }; +enum core_type {VIRTUAL =0 ,PHYSICAL }; +struct channel_packet {uint64_t resource_id;/**< core_num, device */ uint32_t unit;/**< scale down/up/min/max */
@@ -70,6 +73,7 @@ struct channel_packet {uint8_t vcpu_to_control[MAX_VCPU_PER_VM ];uint8_t num_vcpu;struct timer_profile timer_policy; +enum core_type core_type;enum workload workload;enum policy_to_use policy_to_use;struct t_boost_status t_boost_status;
Signature · 1 line
2.17.1
Re: [PATCH v1 2/7] lib/power: add changes for host commands/policies
Quoted 18 lines · On Thu, 30 Aug 2018 11:54:17 +0100 David Hunt <[email protected]> wrote:
Signed-off-by David Hunt <[email protected]>--- lib/librte_power/channel_commands.h | 4 ++++ 1 file changed, 4 insertions(+)lib/librte_power/channel_commands.h +1
-0@@ -19,6 +19,7 @@ extern "C" {#define CPU_POWER 1#define CPU_POWER_CONNECT 2#define PKT_POLICY 3 +#define PKT_POLICY_REMOVE 4/* CPU Power Command Scaling */ #define CPU_POWER_SCALE_UP 1
lib/librte_power/channel_commands.h struct traffic { · line 63
Quoted 5 lines
lib/librte_power/channel_commands.h +2
-0@@ -58,6 +59,8 @@ struct traffic {uint32_t max_max_packet_thresh; }; +enum core_type {VIRTUAL =0 ,PHYSICAL }; +
Why this enum, looks like a boolean to me.
Re: [PATCH v1 2/7] lib/power: add changes for host commands/policies
Hi Stephen,
Quoted 24 lines · Stephen Hemminger
Quoted 21 lines · On Thu, 30 Aug 2018 11:54:17 +0100 David Hunt <[email protected]> wrote:
Signed-off-by David Hunt <[email protected]>--- lib/librte_power/channel_commands.h | 4 ++++ 1 file changed, 4 insertions(+)lib/librte_power/channel_commands.h +1
-0@@ -19,6 +19,7 @@ extern "C" {#define CPU_POWER 1#define CPU_POWER_CONNECT 2#define PKT_POLICY 3 +#define PKT_POLICY_REMOVE 4/* CPU Power Command Scaling */ #define CPU_POWER_SCALE_UP 1@@ -58,6 +59,8 @@ struct traffic {uint32_t max_max_packet_thresh; };
Quoted 3 lines
lib/librte_power/channel_commands.h struct traffic { · line 63
Quoted 2 lines
lib/librte_power/channel_commands.h +2
-0+enum core_type {VIRTUAL =0 ,PHYSICAL }; +Why this enum, looks like a boolean to me.
I'll change this to a 'bool' in the next version.
Thanks,
Dave.
PATCH 3/7 examples/power: add necessary changes to guest app
In reply to David HuntThe changes here are minimal, as the guest app functionality is not changing at all, but there is a new element in the channel_packet struct that needs to have a default set (channel_packet->core_type).
--- examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 1 + 1 file changed, 1 insertion(+)
examples/vm_power_manager/guest_cli/vm_power_cli_guest.c +1 -0
@@ -92,6 +92,7 @@ set_policy_defaults(struct channel_packet *pkt) pkt->timer_policy.hours_to_use_traffic_profile[0 ] =8 ; pkt->timer_policy.hours_to_use_traffic_profile[1 ] =10 ; + pkt->core_type =VIRTUAL ; pkt->workload =LOW ; pkt->policy_to_use =TIME ; pkt->command =PKT_POLICY ;
Signature · 1 line
2.17.1
PATCH 4/7 examples/power: add host channel to power manager
In reply to David HuntThis patch adds a fifo channel to the vm_power_manager app through which we can send commands and polices. Intended for sending JSON strings. The fifo is at /tmp/powermonitor/fifo.0
--- examples/vm_power_manager/channel_manager.c | 108 +++++++++++++++ examples/vm_power_manager/channel_manager.h | 17 ++- examples/vm_power_manager/channel_monitor.c | 146 +++++++++++++++----- examples/vm_power_manager/main.c | 2 + 4 files changed, 238 insertions(+), 35 deletions(-)
examples/vm_power_manager/channel_manager.c +108 -0
@@ -13,6 +13,7 @@#include <sys/queue.h> #include <sys/types.h> +#include <sys/stat.h> #include <sys/socket.h> #include <sys/select.h>
@@ -284,6 +285,38 @@ open_non_blocking_channel(struct channel_info *info)return 0 ; } +static int +open_host_channel (struct channel_info *info) +{ +int flags; + + info->fd =open (info->channel_path,O_RDWR |O_RSYNC ); +if (info->fd ==-1 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error(%s) opening fifo for '%s'\n" , +strerror (errno), + info->channel_path); +return -1 ; + } + +/* Get current flags */ + flags =fcntl (info->fd,F_GETFL ,0 ); +if (flags <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER ,"Error(%s) fcntl get flags socket for" +"'%s'\n" ,strerror (errno), info->channel_path); +return 1 ; + } +/* Set to Non Blocking */ + flags |=O_NONBLOCK ; +if (fcntl (info->fd,F_SETFL , flags) <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER , +"Error(%s) setting non-blocking " +"socket for '%s'\n" , +strerror (errno), info->channel_path); +return -1 ; + } +return 0 ; +} +static int setup_channel_info (struct virtual_machine_info **vm_info_dptr,struct channel_info **chan_info_dptr,unsigned channel_num)
@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, chan_info->channel_num = channel_num; chan_info->priv_info = (void *)vm_info; chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_BINARY ;if (open_non_blocking_channel (chan_info) <0 ) { RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open channel: " "'%s' for VM '%s'\n",
@@ -316,6 +350,35 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr,return 0 ; } +static int +setup_host_channel_info (struct channel_info **chan_info_dptr, +unsigned int channel_num) +{ +struct channel_info *chan_info = *chan_info_dptr; + + chan_info->channel_num = channel_num; + chan_info->priv_info = (void *)0 ; + chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_JSON ; +sprintf (chan_info->channel_path,"%sfifo.0" ,CHANNEL_MGR_SOCKET_PATH ); + +if (open_host_channel (chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could not open host channel: " +"'%s'\n" , + chan_info->channel_path); +return -1 ; + } +if (add_channel_to_monitor (&chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could add channel: " +"'%s' to epoll ctl\n" , + chan_info->channel_path); +return -1 ; + + } + chan_info->status =CHANNEL_MGR_CHANNEL_CONNECTED ; +return 0 ; +} +int add_all_channels (const char *vm_name) {
@@ -470,6 +533,51 @@ add_channels(const char *vm_name, unsigned *channel_list,return num_channels_enabled; } +int +add_host_channel (void ) +{ +struct channel_info *chan_info; +char socket_path[PATH_MAX ]; +int num_channels_enabled =0 ; +int ret; + +snprintf (socket_path,sizeof (socket_path),"%sfifo.%u" , +CHANNEL_MGR_SOCKET_PATH ,0 ); + + errno =0 ; + ret =mkfifo (socket_path,0666 ); +if ((errno !=EEXIST ) && (ret <0 )) { +printf (" %d %d, %d\n" , ret,EEXIST , errno); +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Cannot create fifo '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + + errno =0 ; +if (access (socket_path,F_OK ) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Channel path '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + chan_info =rte_malloc (NULL ,sizeof (*chan_info), +RTE_CACHE_LINE_SIZE ); +if (chan_info ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for " +"channel '%s'\n" , socket_path); +return 0 ; + } +snprintf (chan_info->channel_path, +sizeof (chan_info->channel_path),"%sfifo.%u" , +CHANNEL_MGR_SOCKET_PATH ,0 ); +if (setup_host_channel_info (&chan_info,0 ) <0 ) { +rte_free (chan_info); +return 0 ; + } + num_channels_enabled++; + +return num_channels_enabled; +} +int remove_channel (struct channel_info **chan_info_dptr) {
examples/vm_power_manager/channel_manager.h +16 -1
@@ -37,7 +37,7 @@ struct sockaddr_un _sockaddr_un;#define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path)#endif -#define MAX_VMS 4 +#define MAX_VMS 64#define MAX_VCPUS 20
@@ -54,6 +54,11 @@ enum channel_status { CHANNEL_MGR_CHANNEL_DISCONNECTED = 0,CHANNEL_MGR_CHANNEL_DISABLED , CHANNEL_MGR_CHANNEL_PROCESSING}; +/* Communication Channel Type */ +enum channel_type {CHANNEL_TYPE_BINARY =0 , +CHANNEL_TYPE_INI , +CHANNEL_TYPE_JSON }; +/* VM libvirt(qemu/KVM) connection status */ enum vm_status {CHANNEL_MGR_VM_INACTIVE =0 ,CHANNEL_MGR_VM_ACTIVE };
@@ -66,6 +71,7 @@ struct channel_info {volatile uint32_t status;/**< Connection status(enum channel_status) */ int fd;/**< AF_UNIX socket fd */ unsigned channel_num;/**< CHANNEL_MGR_SOCKET_PATH/<vm_name>.channel_num */ +enum channel_type type;/**< Binary, ini, json, etc. */ void *priv_info;/**< Pointer to private info, do not modify */ };
@@ -226,6 +232,15 @@ int add_all_channels(const char *vm_name);int add_channels (const char *vm_name,unsigned *channel_list,unsigned num_channels); +/** +* Set up a fifo by which host applications can send command an policies +* through a fifo to the vm_power_manager +* +* @return +* - 0 for success +*/ +int add_host_channel (void ); +/** * Remove a channel definition from the channel manager. This must only be * called from the channel monitor thread.
examples/vm_power_manager/channel_monitor.c +112 -34
225 lines not on this page · raw message
examples/vm_power_manager/main.c +2 -0
@@ -421,6 +421,8 @@ main(int argc, char **argv)return -1 ; } +add_host_channel (); +printf ("Running core monitor on lcore id %d\n" , lcore_id);rte_eal_remote_launch (run_core_monitor,NULL , lcore_id);
Signature · 1 line
2.17.1
Re: [PATCH v1 4/7] examples/power: add host channel to power manager
Quoted 359 lines
-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of David Hunt
Sent: Thursday, August 30, 2018 6:54 PM
To: [email protected]
Cc: Mcnamara, John <[email protected]>; Hunt, David <[email protected]>
Subject: [dpdk-dev] [PATCH v1 4/7] examples/power: add host channel to power managerThis patch adds a fifo channel to the
vm_power_managerapp through which we can send commands and polices. Intended for sending JSON strings. The fifo is at/tmp/powermonitor/fifo.0Signed-off-by David Hunt <[email protected]>--- examples/vm_power_manager/channel_manager.c | 108 +++++++++++++++ examples/vm_power_manager/channel_manager.h | 17 ++- examples/vm_power_manager/channel_monitor.c | 146 +++++++++++++++----- examples/vm_power_manager/main.c | 2 + 4 files changed, 238 insertions(+), 35 deletions(-)examples/vm_power_manager/channel_manager.c +18
-0@@ -13,6 +13,7 @@#include <sys/queue.h> #include <sys/types.h> +#include <sys/stat.h> #include <sys/socket.h> #include <sys/select.h> @@ -284,6 +285,38 @@ open_non_blocking_channel(struct channel_info *info)return 0 ; } +static int +open_host_channel (struct channel_info *info) +{ +int flags; + + info->fd =open (info->channel_path,O_RDWR |O_RSYNC ); +if (info->fd ==-1 ) { + RTE_LOG(ERR, CHANNEL_MANAGER, "Error(%s) opening fifo for '%s'\n", +strerror (errno), + info->channel_path); +return -1 ; + } + +/* Get current flags */ + flags =fcntl (info->fd,F_GETFL ,0 ); +if (flags <0 ) { + RTE_LOG(WARNING, CHANNEL_MANAGER, "Error(%s) fcntlget flags socket for"
examples/vm_power_manager/channel_manager.c +1
-0+ "'%s'\n", strerror(errno), info-Quoted 1 line
channel_path);examples/vm_power_manager/channel_manager.c +14
-0+return 1 ; + } +/* Set to Non Blocking */ + flags |=O_NONBLOCK ; +if (fcntl (info->fd,F_SETFL , flags) <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER , +"Error(%s) setting non-blocking " +"socket for '%s'\n" , +strerror (errno), info->channel_path); +return -1 ; + } +return 0 ; +} +static int setup_channel_info (struct virtual_machine_info **vm_info_dptr, struct channel_info **chan_info_dptr, unsigned
channel_num)examples/vm_power_manager/channel_manager.c +1
-0@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, chan_info->channel_num = channel_num; chan_info->priv_info = (void *)vm_info; chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_BINARY ;if (open_non_blocking_channel (chan_info) <0 ) { RTE_LOG(ERR, CHANNEL_MANAGER, "Could not openchannel: "
examples/vm_power_manager/channel_manager.c +14
-0"'%s' for VM '%s'\n",@@ -316,6 +350,35 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, return 0; } +static int +setup_host_channel_info (struct channel_info **chan_info_dptr, +unsigned int channel_num) +{ +struct channel_info *chan_info = *chan_info_dptr; + + chan_info->channel_num = channel_num; + chan_info->priv_info = (void *)0 ; + chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_JSON ; +sprintf (chan_info->channel_path,"%sfifo.0" ,CHANNEL_MGR_SOCKET_PATH ); + +if (open_host_channel (chan_info) <0 ) { + RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open hostchannel: "
examples/vm_power_manager/channel_manager.c +31
-0+"'%s'\n" , + chan_info->channel_path); +return -1 ; + } +if (add_channel_to_monitor (&chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could add channel: " +"'%s' to epoll ctl\n" , + chan_info->channel_path); +return -1 ; + + } + chan_info->status =CHANNEL_MGR_CHANNEL_CONNECTED ; +return 0 ; +} +int add_all_channels (const char *vm_name) {@@ -470,6 +533,51 @@ add_channels(const char *vm_name, unsigned *channel_list, return num_channels_enabled; } +int +add_host_channel (void ) +{ +struct channel_info *chan_info; +char socket_path[PATH_MAX ]; +int num_channels_enabled =0 ; +int ret; + +snprintf (socket_path,sizeof (socket_path),"%sfifo.%u" , +CHANNEL_MGR_SOCKET_PATH ,0 ); + + errno =0 ; + ret =mkfifo (socket_path,0666 ); +if ((errno !=EEXIST ) && (ret <0 )) { +printf (" %d %d, %d\n" , ret,EEXIST , errno); + RTE_LOG(ERR, CHANNEL_MANAGER, "Cannot create fifo '%s'error: "
examples/vm_power_manager/channel_manager.c +7
-0+ "%s\n", socket_path, strerror(errno)); +return 0 ; + } + + errno =0 ; +if (access (socket_path,F_OK ) <0 ) { + RTE_LOG(ERR, CHANNEL_MANAGER, "Channel path '%s'error: "
examples/vm_power_manager/channel_manager.c +7
-0+ "%s\n", socket_path, strerror(errno)); +return 0 ; + } + chan_info =rte_malloc (NULL ,sizeof (*chan_info), +RTE_CACHE_LINE_SIZE ); +if (chan_info ==NULL ) { + RTE_LOG(ERR, CHANNEL_MANAGER, "Error allocatingmemory for "
examples/vm_power_manager/channel_manager.c +15
-0+ "channel '%s'\n", socket_path); +return 0 ; + } +snprintf (chan_info->channel_path, +sizeof (chan_info->channel_path),"%sfifo.%u" , +CHANNEL_MGR_SOCKET_PATH ,0 ); +if (setup_host_channel_info (&chan_info,0 ) <0 ) { +rte_free (chan_info); +return 0 ; + } + num_channels_enabled++; + +return num_channels_enabled; +} +int remove_channel (struct channel_info **chan_info_dptr) {examples/vm_power_manager/channel_manager.h +6
-1@@ -37,7 +37,7 @@ struct sockaddr_un _sockaddr_un;#define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path)#endif -#define MAX_VMS 4 +#define MAX_VMS 64#define MAX_VCPUS 20@@ -54,6 +54,11 @@ enum channel_status {CHANNEL_MGR_CHANNEL_DISCONNECTED =0 ,CHANNEL_MGR_CHANNEL_DISABLED , CHANNEL_MGR_CHANNEL_PROCESSING}; +/* Communication Channel Type */ +enum channel_type {CHANNEL_TYPE_BINARY =0 , +CHANNEL_TYPE_INI , +CHANNEL_TYPE_JSON }; +/* VM libvirt(qemu/KVM) connection status */ enum vm_status { CHANNEL_MGR_VM_INACTIVE = 0,
CHANNEL_MGR_VM_ACTIVE};examples/vm_power_manager/channel_manager.h +0
-0@@ -66,6 +71,7 @@ struct channel_info {volatile uint32_t status;/**< Connection status(enum
channel_status) */examples/vm_power_manager/channel_manager.h +0
-0int fd;/**< AF_UNIX socket fd */ unsigned channel_num;/**< CHANNEL_MGR_SOCKET_PATH/<vm_name>.channel_num */
examples/vm_power_manager/channel_manager.h +10
-0+enum channel_type type;/**< Binary, ini, json, etc. */ void *priv_info;/**< Pointer to private info, do not modify */ };@@ -226,6 +232,15 @@ int add_all_channels(const char *vm_name);int add_channels (const char *vm_name,unsigned *channel_list,unsigned num_channels); +/** +* Set up a fifo by which host applications can send command an policies +* through a fifo to the vm_power_manager +* +* @return +* - 0 for success +*/ +int add_host_channel (void ); +/** * Remove a channel definition from the channel manager. This must only be * called from the channel monitor thread. examples/vm_power_manager/channel_monitor.c +27
-0@@ -85,6 +85,33 @@ core_share_status(int pNo) } } + +static int +pcpu_monitor (struct policy *pol,struct core_info *ci,int pcpu,int count) +{ +int ret =0 ; + +if (pol->pkt.policy_to_use ==BRANCH_RATIO ) { + ci->cd[pcpu].oob_enabled =1 ; + ret =add_core_to_monitor (pcpu); +if (ret ==0 ) +RTE_LOG (INFO ,CHANNEL_MONITOR , +"Monitoring pcpu %d OOB for %s\n" , + pcpu, pol->pkt.vm_name); +else +RTE_LOG (ERR ,CHANNEL_MONITOR , + "Error monitoring pcpu %d OOB for %s\n", + pcpu, pol->pkt.vm_name); + + }else { + pol->core_share[count].pcpu = pcpu; +RTE_LOG (INFO ,CHANNEL_MONITOR , +"Monitoring pcpu %d for %s\n" , + pcpu, pol->pkt.vm_name); + } +return ret; +} +static void get_pcpu_to_control (struct policy *pol){
examples/vm_power_manager/channel_monitor.c +6
-23@@ -94,34 +121,46 @@ get_pcpu_to_control(struct policy *pol)int pcpu, count;uint64_t mask_u64b;struct core_info *ci; -int ret; ci =get_core_info (); -RTE_LOG (INFO ,CHANNEL_MONITOR ,"Looking for pcpu for %s\n" , - pol->pkt.vm_name); -get_info_vm (pol->pkt.vm_name, &info); - -for (count =0 ; count < pol->pkt.num_vcpu; count++) { - mask_u64b = info.pcpu_mask[pol- >pkt.vcpu_to_control[count]]; -for (pcpu =0 ; mask_u64b; mask_u64b &= ~(1ULL << pcpu++)) { -if ((mask_u64b >> pcpu) &1 ) { -if (pol->pkt.policy_to_use ==BRANCH_RATIO ) { - ci->cd[pcpu].oob_enabled =1 ; - ret =add_core_to_monitor (pcpu); -if (ret ==0 ) - printf("Monitoring pcpu %d via Branch Ratio\n", - pcpu); -else - printf("Failed to start OOB Monitoring pcpu %d\n", - pcpu); - - }else { - pol->core_share[count].pcpu = pcpu; -printf ("Monitoring pcpu %d\n" , pcpu); - } +RTE_LOG (INFO ,CHANNEL_MONITOR , + "Looking for pcpu for %s\n", pol->pkt.vm_name); + +/* +* So now that we're handling virtual and physical cores, we need to +* differenciate between them when adding them to the branch monitor.
examples/vm_power_manager/channel_monitor.c +16
-0+* Virtual cores need to be converted to physical cores. +*/ + + + + +if (pol->pkt.core_type ==VIRTUAL ) { +/* +* If the cores in the policy are virtual, we need to map them +* to physical core. We look up the vm info and use that for +* the mapping. +*/ +get_info_vm (pol->pkt.vm_name, &info); +for (count =0 ; count < pol->pkt.num_vcpu; count++) { + mask_u64b = + info.pcpu_mask[pol-Quoted 1 line
pkt.vcpu_to_control[count]];
examples/vm_power_manager/channel_monitor.c +13
-0+for (pcpu =0 ; mask_u64b; + mask_u64b &= ~(1ULL << pcpu++)) { +if ((mask_u64b >> pcpu) &1 ) +pcpu_monitor (pol, ci, pcpu, count); } } + }else { +/* +* If the cores in the policy are physical, we just use +* those core id's directly. +*/ +for (count =0 ; count < pol->pkt.num_vcpu; count++) { + pcpu = pol->pkt.vcpu_to_control[count]; +pcpu_monitor (pol, ci, pcpu, count); + } } }
examples/vm_power_manager/channel_monitor.c update_policy(struct channel_packet *pkt) · line 207
Quoted 9 lines
examples/vm_power_manager/channel_monitor.c +4
-0@@ -160,8 +199,13 @@ update_policy(struct channel_packet *pkt)unsigned int updated =0 ;int i; + +RTE_LOG (INFO ,CHANNEL_MONITOR , +"Updating policy for %s\n" , pkt->vm_name); +for (i =0 ; i <MAX_VMS ; i++) {if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) {
I suggest add warning log here when no VM can match the policy name which we send through the fifo.0. Otherwise, the user can't aware the policy won't be applied.
Quoted 155 lines
examples/vm_power_manager/channel_monitor.c +19
-1+/* Copy the contents of *pkt into the policy.pkt */ policies[i].pkt = *pkt;get_pcpu_to_control (&policies[i]);if (get_pfid (&policies[i]) ==-1 ) {@@ -189,6 +233,24 @@ update_policy(struct channel_packet *pkt)return 0 ; } +static int +remove_policy(struct channel_packet *pkt __rte_unused) +{ +int i; + +/* +* Disabling the policy is simply a case of setting +* enabled to 0 +*/ +for (i =0 ; i <MAX_VMS ; i++) { +if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) { + policies[i].enabled =0 ; +return 0 ; + } + } +return -1 ; +} +static uint64_t get_pkt_diff (struct policy *pol) {@@ -346,7 +408,6 @@ apply_policy(struct policy *pol)apply_workload_profile (pol); } -static int process_request (struct channel_packet *pkt,struct channel_info *chan_info){
examples/vm_power_manager/channel_monitor.c +2
-0@@ -355,6 +416,8 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info)if (chan_info ==NULL )return -1 ; +RTE_LOG (INFO ,CHANNEL_MONITOR ,"Processing Request %s\n" , pkt->vm_name); + if (rte_atomic32_cmpset(&(chan_info->status),
CHANNEL_MGR_CHANNEL_CONNECTED,examples/vm_power_manager/channel_monitor.c +0
-1CHANNEL_MGR_CHANNEL_PROCESSING) == 0)return -1 ;@@ -362,10 +425,12 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info)if (pkt->command ==CPU_POWER ) { core_mask =get_pcpus_mask (chan_info, pkt->resource_id);if (core_mask ==0 ) { - RTE_LOG(ERR, CHANNEL_MONITOR, "Error getphysical CPU mask for "
examples/vm_power_manager/channel_monitor.c +0
-1- "channel '%s' using vCPU(%u)\n", chan_info-Quoted 1 line
channel_path,examples/vm_power_manager/channel_monitor.c +8
-4- (unsigned)pkt->unit); -return -1 ; +/* +* Core mask will be 0 in the case where +* hypervisor is not available so we're working in +* the host, so use the core as the mask. +*/ + core_mask =1 << pkt->resource_id; }if (__builtin_popcountll (core_mask) ==1 ) {@@ -421,12 +486,20 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info) }if (pkt->command ==PKT_POLICY ) { - RTE_LOG(INFO, CHANNEL_MONITOR, "\nProcessing Policy request from Guest\n"); +RTE_LOG (INFO ,CHANNEL_MONITOR , +"\nProcessing Policy request\n" );update_policy (pkt); policy_is_set =1 ; } -/* Return is not checked as channel status may have been set to DISABLED
examples/vm_power_manager/channel_monitor.c +8
-0+if (pkt->command ==PKT_POLICY_REMOVE ) { +RTE_LOG (INFO ,CHANNEL_MONITOR , +"Removing policy %s\n" , pkt->vm_name); +remove_policy (pkt); + } + +/* +* Return is not checked as channel status may have been set to DISABLED
examples/vm_power_manager/channel_monitor.c +0
-0* from management thread */ rte_atomic32_cmpset(&(chan_info->status),
CHANNEL_MGR_CHANNEL_PROCESSING,examples/vm_power_manager/channel_monitor.c +4
-1@@ -448,13 +521,16 @@ add_channel_to_monitor(struct channel_info **chan_info) "to epoll\n", info->channel_path);return -1 ; } +RTE_LOG (ERR ,CHANNEL_MONITOR ,"Added channel '%s' " +"to monitor\n" , info->channel_path);return 0 ; }int remove_channel_from_monitor (struct channel_info *chan_info) { -if (epoll_ctl (global_event_fd,EPOLL_CTL_DEL , chan_info->fd,NULL ) < 0) { +if (epoll_ctl (global_event_fd,EPOLL_CTL_DEL , + chan_info->fd,NULL ) <0 ) { RTE_LOG(ERR, CHANNEL_MONITOR, "Unable to removechannel '%s' "
examples/vm_power_manager/channel_monitor.c +0
-1"from epoll\n", chan_info->channel_path);return -1 ;@@ -467,11 +543,13 @@ channel_monitor_init(void) { global_event_fd =epoll_create1 (0 );if (global_event_fd ==0 ) { - RTE_LOG(ERR, CHANNEL_MONITOR, "Error creating epollcontext with "
examples/vm_power_manager/channel_monitor.c +3
-2- "error %s\n", strerror(errno)); +RTE_LOG (ERR ,CHANNEL_MONITOR , +"Error creating epoll context with error %s\n" , +strerror (errno));return -1 ; } - global_events_list = rte_malloc("epoll_events",
sizeof(*global_events_list)examples/vm_power_manager/channel_monitor.c +2
-0+ global_events_list =rte_malloc ("epoll_events" , +sizeof (*global_events_list) *MAX_EVENTS ,RTE_CACHE_LINE_SIZE );if (global_events_list ==NULL ) { RTE_LOG(ERR, CHANNEL_MONITOR, "Unable to rte_mallocfor "
examples/vm_power_manager/main.c +2
-1@@ -421,6 +421,8 @@ main(int argc, char **argv)return -1 ; } +add_host_channel (); +printf ("Running core monitor on lcore id %d\n" , lcore_id);rte_eal_remote_launch (run_core_monitor,NULL , lcore_id); --2.17.1
Re: [PATCH v1 4/7] examples/power: add host channel to power manager
Hi Lei,
Quoted 24 lines · Lei A
Quoted 24 lines
-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of David Hunt
Sent: Thursday, August 30, 2018 6:54 PM
To: [email protected]
Cc: Mcnamara, John <[email protected]>; Hunt, David <[email protected]>
Subject: [dpdk-dev] [PATCH v1 4/7] examples/power: add host channel to power managerThis patch adds a fifo channel to the
vm_power_managerapp through which we can send commands and polices. Intended for sending JSON strings. The fifo is at/tmp/powermonitor/fifo.0Signed-off-by David Hunt <[email protected]>--- examples/vm_power_manager/channel_manager.c | 108 +++++++++++++++ examples/vm_power_manager/channel_manager.h | 17 ++- examples/vm_power_manager/channel_monitor.c | 146 +++++++++++++++----- examples/vm_power_manager/main.c | 2 + 4 files changed, 238 insertions(+), 35 deletions(-)
Quoted 6 lines
examples/vm_power_manager/channel_manager.c
Quoted 6 lines
examples/vm_power_manager/channel_manager.c +0
-0@@ -13,6 +13,7 @@
--snip--
Quoted 5 lines
Quoted 5 lines
examples/vm_power_manager/channel_manager.c +0
-0@@ -160,8 +199,13 @@ update_policy(struct channel_packet *pkt)unsigned int updated =0 ;int i;
Quoted 9 lines
examples/vm_power_manager/channel_manager.c update_policy(struct channel_packet *pkt) · line 207
Quoted 6 lines
examples/vm_power_manager/channel_manager.c +4
-0+ +RTE_LOG (INFO ,CHANNEL_MONITOR , +"Updating policy for %s\n" , pkt->vm_name); +for (i =0 ; i <MAX_VMS ; i++) {if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) {I suggest add warning log here when no VM can match the policy name which we send through the fifo.0. Otherwise, the user can't aware the policy won't be applied.
There's already a flag here called "updated" that if it falls through this loop without finding the policy name, it adds a new one, so no need for the message. I will however re-word the "Updating policy" message to read "Applying policy". "Applying" is less confusing.
Thanks,
Dave.
---snip---
PATCH 5/7 examples/power: add json string handling
In reply to David HuntAdd JSON string handling to vm_power_manager for JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, the vm_power_manager user guide documentation updates.
This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
--- examples/vm_power_manager/Makefile | 2 +- examples/vm_power_manager/channel_monitor.c | 295 +++++++++++++++++--- 2 files changed, 252 insertions(+), 45 deletions(-)
examples/vm_power_manager/Makefile +1 -1
@@ -29,7 +29,7 @@ endif CFLAGS += -O3 -I$(RTE_SDK)/lib/librte_power/ CFLAGS += $(WERROR_FLAGS) -LDLIBS += -lvirt +LDLIBS += -lvirt -ljansson ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
examples/vm_power_manager/channel_monitor.c +251 -44
381 lines not on this page · raw message
Signature · 1 line
2.17.1
Re: [PATCH v1 5/7] examples/power: add json string handling
Quoted 10 lines · On Thu, 30 Aug 2018 11:54:20 +0100 David Hunt <[email protected]> wrote:
Add JSON string handling to
vm_power_managerfor JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, thevm_power_manageruser guide documentation updates.This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
Signed-off-by David Hunt <[email protected]>
If you introduce new dependency then it has to be in documentation, and off by default in Makefile, and checked in meson build.
Re: [PATCH v1 5/7] examples/power: add json string handling
Quoted 7 lines · Stephen Hemminger
Quoted 4 lines · On Thu, 30 Aug 2018 11:54:20 +0100 David Hunt <[email protected]> wrote:
Add JSON string handling to
vm_power_managerfor JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, thevm_power_manageruser guide documentation updates.
Quoted 8 lines
Quoted 6 lines
This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
Signed-off-by David Hunt <[email protected]>If you introduce new dependency then it has to be in documentation, and off by default in
Makefile, and checked in meson build.
Hi Stephen,
Thanks for the review. I'll address your comments, and get a new version up soon after Userspace. Rgds,
Dave.
Re: [PATCH v1 5/7] examples/power: add json string handling
In reply to Stephen HemmingerHi Stephen,
Quoted 7 lines · Stephen Hemminger
Quoted 4 lines · On Thu, 30 Aug 2018 11:54:20 +0100 David Hunt <[email protected]> wrote:
Add JSON string handling to
vm_power_managerfor JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, thevm_power_manageruser guide documentation updates.
Quoted 8 lines
Quoted 6 lines
This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
Signed-off-by David Hunt <[email protected]>If you introduce new dependency then it has to be in documentation, and off by default in
Makefile, and checked in meson build.
Sure, I've added a check in the Makefile for the existence of the library, and it will build in the JSON handling if present, otherwise warn the user and build without.
Thanks,
Dave.
PATCH 6/7 doc/vm_power_manager: add JSON interface API info
In reply to David Hunt--- .../sample_app_ug/vm_power_management.rst | 195 ++++++++++++++++++ 1 file changed, 195 insertions(+)
doc/guides/sample_app_ug/vm_power_management.rst +195 -0
@@ -337,6 +337,201 @@ monitoring of branch ratio on cores doing busy polling via PMDs. and will need to be adjusted for different workloads. + +JSON API +~~~~~~~~ + +In addition to the command line interface for host command and a virtio-serial +interface for VM power policies, there is also a JSON interface through which +power commands and policies can be sent. Sending a command or policy to the +power manager application is achieved by simply opening a fifo file, writing +a JSON string to that fifo, and closing the file. + +The fifo is at /tmp/powermonitor/fifo.0 + +The jason string can be a policy or instruction, and takes the following +format: + + .. code-block:: console + + {"packet_type": { + "pair_1": value, + "pair_2": value + }} + +The 'packet_type' header can contain one of two values, depending on +whether a policy or power command is being sent. The two possible values are +"policy" and "instruction", and the expected name-value pairs is different +depending on which type is being sent. + +The pairs are the format of standard JSON name-value pairs. The value type +varies between the different name/value pairs, and may be intgers, strings, +arrays, etc. Examples of policies follow later in this document. The allowed +names and value types are as follows: + + +:Pair Name: "name" +:Description: Name of the VM or Host. Allows the parser to associate the + policy with the relevant VM or Host OS. +:Type: string +:Values: any valid string +:Required: yes +:Example: + + .. code-block:: console + + ""name", "ubuntu2" + + +:Pair Name: "command" +:Description: The type of packet we're sending to the power manager. We can be + creating or destroying a policy, or sending a direct command to adjust + the frequency of a core, similar to the command line interface. +:Type: string +:Values: + + :"CREATE": used when creating a new policy, + :"DESTROY": used when removing a policy, + :"POWER": used when sending an immediate command, max, min, etc. +:Required: yes +:Example: + + .. code-block:: console + + "command", "CREATE" + + +:Pair Name: "policy_type" +:Description: Type of policy to apply. Please see vm_power_manager documentation + for more information on the types of policies that may be used. +:Type: string +:Values: + + :"TIME": Time-of-day policy. Frequencies of the relevant cores are + scaled up/down depending on busy and quiet hours. + :"TRAFFIC": This policy takes statistics from the NIC and scales up + and down accordingly. + :"WORKLOAD": This policy looks at how heavily loaded the cores are, + and scales up and down accordingly. + :"BRANCH_RATIO": This out-of-band policy can look at the ratio between + branch hits and misses on a core, and is useful for detecting + how much packet processing a core is doing. +:Required: only for CREATE/DESTROY command +:Example: + + .. code-block:: console + + "policy_type", "TIME" + +:Pair Name: "busy_hours" +:Description: The hours of the day in which we scale up the cores for busy + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console + + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ] + +:Pair Name: "quiet_hours" +:Description: The hours of the day in which we scale down the cores for quiet + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console + + "quiet_hours":[ 2, 3, 4, 5, 6 ] + +:Pair Name: "core_list" +:Description: The cores to which to apply the policy. +:Type: array of integers +:Values: array with list of virtual CPUs. +:Required: only policy CREATE/DESTROY +:Example: + + .. code-block:: console + + "core_list":[ 10, 11 ] + +:Pair Name: "unit" +:Description: the type of power operation to apply in the command +:Type: string +:Values: + + :"SCALE_MAX": Scale frequency of this core to maximum + :"SCALE_MIN": Scale frequency of this core to minimum + :"SCALE_UP": Scale up frequency of this core + :"SCALE_DOWN": Scale down frequency of this core + :"ENABLE_TURBO": Enable Turbo Boost for this core + :"DISABLE_TURBO": Disable Turbo Boost for this core +:Required: only for POWER instruction +:Example: + + .. code-block:: console + + "unit", "SCALE_MAX" + +:Pair Name: "resource_id" +:Description: The core to which to apply the power command. +:Type: integer +:Values: valid core id for VM or host OS. +:Required: only POWER instruction +:Example: + + .. code-block:: console + + "resource_id": 10 + +JSON API Examples +~~~~~~~~~~~~~~~~~ + +Profile create example: + + .. code-block:: console + + {"policy": { + "name": "ubuntu", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11 ] + }} + +Profile destroy example: + + .. code-block:: console + + {"profile": { + "name": "ubuntu", + "command": "destroy", + }} + +Power command example: + + .. code-block:: console + + {"command": { + "name": "ubuntu", + "unit": "SCALE_MAX", + "resource_id": 10 + }} + +To send a JSON string to the Power Manager application, simply paste the +example JSON string into a text file and cat it into the fifo: + + .. code-block:: console + + cat file.json >/tmp/powermonitor/fifo.0 + +The console of the Power Manager application should indicate the command that +was just received via the fifo. + Compiling and Running the Guest Applications --------------------------------------------
Signature · 1 line
2.17.1
Re: [PATCH v1 6/7] doc/vm_power_manager: add JSON interface API info
Quoted 134 lines
-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of David Hunt
Sent: Thursday, August 30, 2018 6:54 PM
To: [email protected]
Cc: Mcnamara, John <[email protected]>; Hunt, David <[email protected]>
Subject: [dpdk-dev] [PATCH v1 6/7] doc/vm_power_manager: add JSON interface API infoSigned-off-by David Hunt <[email protected]>--- .../sample_app_ug/vm_power_management.rst | 195 ++++++++++++++++++ 1 file changed, 195 insertions(+)doc/guides/sample_app_ug/vm_power_management.rst +0
-0@@ -337,6 +337,201 @@ monitoring of branch ratio on cores doing busypolling via PMDs.
and will need to be adjusted for different workloads.doc/guides/sample_app_ug/vm_power_management.rst +5
-0+ +JSON API +~~~~~~~~ + +In addition to the command line interface for host command and a virtio-serial
+interface for VM power policies, there is also a JSON interface through which
+power commands and policies can be sent. Sending a command or policy to thedoc/guides/sample_app_ug/vm_power_management.rst +17
-0+power manager application is achieved by simply opening a fifo file, writing +a JSON string to that fifo, and closing the file. + +The fifo is at /tmp/powermonitor/fifo.0 + +The jason string can be a policy or instruction, and takes the following +format: + + .. code-block:: console + + {"packet_type": { + "pair_1": value, + "pair_2": value + }} + +The 'packet_type' header can contain one of two values, depending on +whether a policy or power command is being sent. The two possible valuesare
+"policy" and "instruction", and the expected name-value pairs is differentdoc/guides/sample_app_ug/vm_power_management.rst +23
-0+depending on which type is being sent. + +The pairs are the format of standard JSON name-value pairs. The value type +varies between the different name/value pairs, and may be intgers, strings, +arrays, etc. Examples of policies follow later in this document. The allowed +names and value types are as follows: + + +:Pair Name: "name" +:Description: Name of the VM or Host. Allows the parser to associate the + policy with the relevant VM or Host OS. +:Type: string +:Values: any valid string +:Required: yes +:Example: + + .. code-block:: console + + ""name", "ubuntu2" + + +:Pair Name: "command" +:Description: The type of packet we're sending to the power manager. Wecan be
doc/guides/sample_app_ug/vm_power_management.rst +18
-0+ creating or destroying a policy, or sending a direct command to adjust + the frequency of a core, similar to the command line interface. +:Type: string +:Values: + + :"CREATE": used when creating a new policy, + :"DESTROY": used when removing a policy, + :"POWER": used when sending an immediate command, max, min, etc. +:Required: yes +:Example: + + .. code-block:: console + + "command", "CREATE" + + +:Pair Name: "policy_type" +:Description: Type of policy to apply. Please see vm_power_managerdocumentation
doc/guides/sample_app_ug/vm_power_management.rst +34
-0+ for more information on the types of policies that may be used. +:Type: string +:Values: + + :"TIME": Time-of-day policy. Frequencies of the relevant cores are + scaled up/down depending on busy and quiet hours. + :"TRAFFIC": This policy takes statistics from the NIC and scales up + and down accordingly. + :"WORKLOAD": This policy looks at how heavily loaded the cores are, + and scales up and down accordingly. + :"BRANCH_RATIO": This out-of-band policy can look at the ratio between + branch hits and misses on a core, and is useful for detecting + how much packet processing a core is doing. +:Required: only for CREATE/DESTROY command +:Example: + + .. code-block:: console + + "policy_type", "TIME" + +:Pair Name: "busy_hours" +:Description: The hours of the day in which we scale up the cores for busy + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console + + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ] + +:Pair Name: "quiet_hours" +:Description: The hours of the day in which we scale down the cores forquiet
doc/guides/sample_app_ug/vm_power_management.rst monitoring of branch ratio on cores doing busy polling via PMDs. · line 449
Quoted 10 lines
doc/guides/sample_app_ug/vm_power_management.rst +10
-0+ times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console + + "quiet_hours":[ 2, 3, 4, 5, 6 ] +
Do you think we need document following three key here? min_packet_threshavg_packet_threshmax_packet_thresh
I see them in the code but not documented.
Quoted 91 lines
+:Pair Name: "
core_list"
+:Description: The cores to which to apply the policy. +:Type: array of integers
+:Values: array with list of virtual CPUs. +:Required: only policy CREATE/DESTROY +:Example:doc/guides/sample_app_ug/vm_power_management.rst +77
-0+ + .. code-block:: console + + "core_list":[ 10, 11 ] + +:Pair Name: "unit" +:Description: the type of power operation to apply in the command +:Type: string +:Values: + + :"SCALE_MAX": Scale frequency of this core to maximum + :"SCALE_MIN": Scale frequency of this core to minimum + :"SCALE_UP": Scale up frequency of this core + :"SCALE_DOWN": Scale down frequency of this core + :"ENABLE_TURBO": Enable Turbo Boost for this core + :"DISABLE_TURBO": Disable Turbo Boost for this core +:Required: only for POWER instruction +:Example: + + .. code-block:: console + + "unit", "SCALE_MAX" + +:Pair Name: "resource_id" +:Description: The core to which to apply the power command. +:Type: integer +:Values: valid core id for VM or host OS. +:Required: only POWER instruction +:Example: + + .. code-block:: console + + "resource_id": 10 + +JSON API Examples +~~~~~~~~~~~~~~~~~ + +Profile create example: + + .. code-block:: console + + {"policy": { + "name": "ubuntu", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11 ] + }} + +Profile destroy example: + + .. code-block:: console + + {"profile": { + "name": "ubuntu", + "command": "destroy", + }} + +Power command example: + + .. code-block:: console + + {"command": { + "name": "ubuntu", + "unit": "SCALE_MAX", + "resource_id": 10 + }} + +To send a JSON string to the Power Manager application, simply paste the +example JSON string into a text file and cat it into the fifo: + + .. code-block:: console + + cat file.json >/tmp/powermonitor/fifo.0 + +The console of the Power Manager application should indicate thecommand that
doc/guides/sample_app_ug/vm_power_management.rst +2
-1+was just received via the fifo. + Compiling and Running the Guest Applications -------------------------------------------- --2.17.1
Re: [PATCH v1 6/7] doc/vm_power_manager: add JSON interface API info
Hi Lei,
Quoted 26 lines · Lei A
Quoted 26 lines
-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of David Hunt
Sent: Thursday, August 30, 2018 6:54 PM
To: [email protected]
Cc: Mcnamara, John <[email protected]>; Hunt, David <[email protected]>
Subject: [dpdk-dev] [PATCH v1 6/7] doc/vm_power_manager: add JSON interface API infoSigned-off-by David Hunt <[email protected]>--- .../sample_app_ug/vm_power_management.rst | 195 ++++++++++++++++++ 1 file changed, 195 insertions(+)doc/guides/sample_app_ug/vm_power_management.rst +0
-0@@ -337,6 +337,201 @@ monitoring of branch ratio on cores doing busypolling via PMDs.
and will need to be adjusted for different workloads.
Quoted 4 lines
doc/guides/sample_app_ug/vm_power_management.rst monitoring of branch ratio on cores doing busy polling via PMDs. · line 343
Quoted 4 lines
doc/guides/sample_app_ug/vm_power_management.rst +4
-0+ +JSON API +~~~~~~~~ +
--snip--
Quoted 10 lines
Quoted 10 lines
+:Pair Name: "
quiet_hours"
+:Description: The hours of the day in which we scale down the cores for quietdoc/guides/sample_app_ug/vm_power_management.rst +7
-0+ times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console
Quoted 9 lines
doc/guides/sample_app_ug/vm_power_management.rst monitoring of branch ratio on cores doing busy polling via PMDs. · line 449
Quoted 3 lines
doc/guides/sample_app_ug/vm_power_management.rst +3
-0+ + "quiet_hours":[ 2, 3, 4, 5, 6 ] +Do you think we need document following three key here?
min_packet_threshavg_packet_threshmax_packet_thresh
I see them in the code but not documented.
Good catch. I missed these in the docs. Also I checked the code there these are used, and only two are needed. These are avg and max.
Below, avg, the freq is set to minimum
Between avg and max, the freq us set to medium
Above max, the freq is set to maximum.
I'll remove the minimum from the code, seeing as it's not used, and document avg and max.
Rgds,
Dave.
--snip--
PATCH 7/7 examples/power: add json example files
In reply to David HuntThis patch provides some example files in the json_examples sub-directory for sending to the fifo.
--- examples/vm_power_manager/json_examples/README | 6 ++++++ examples/vm_power_manager/json_examples/create.json | 8 ++++++++ examples/vm_power_manager/json_examples/destroy.json | 4 ++++ examples/vm_power_manager/json_examples/set_core_max.json | 6 ++++++ examples/vm_power_manager/json_examples/set_core_min.json | 6 ++++++ 5 files changed, 30 insertions(+) create mode 100644 examples/vm_power_manager/json_examples/README create mode 100644 examples/vm_power_manager/json_examples/create.json create mode 100644 examples/vm_power_manager/json_examples/destroy.json create mode 100644 examples/vm_power_manager/json_examples/set_core_max.json create mode 100644 examples/vm_power_manager/json_examples/set_core_min.json
examples/vm_power_manager/json_examples/README new file +6 -0
@@ -0,0 +1,6 @@ +Sample files for sending to the vm_power_manager through the fifo. + +Simply cat the file to /tmp/powermonitor/fifo.0 when the vm_power_manager +application is running. + +E.g. cat create.json >/tmp/powermonitor/fifo.0
examples/vm_power_manager/json_examples/create.json new file +8 -0
@@ -0,0 +1,8 @@ +{"policy": { + "name": "policy-1", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11, 12 ] +}}
examples/vm_power_manager/json_examples/destroy.json new file +4 -0
@@ -0,0 +1,4 @@ +{"policy": { + "name": "policy-1", + "command": "destroy" +}}
examples/vm_power_manager/json_examples/set_core_max.json new file +6 -0
@@ -0,0 +1,6 @@ +{"instruction": { + "name": "set_power", + "command": "power", + "unit": "SCALE_MAX", + "resource_id": 10 +}}
examples/vm_power_manager/json_examples/set_core_min.json new file +6 -0
@@ -0,0 +1,6 @@ +{"instruction": { + "name": "set_power", + "command": "power", + "unit": "SCALE_MIN", + "resource_id": 10 +}}
Signature · 1 line
2.17.1
v2 cover add json power policy interface for containers
In reply to David HuntPatch v2:
* Fixed review comments from Stephen Hemminger and Lei A Yao.
* Added a check in the Makefile for libjansson-dev. Will Warn user and build without JSON functionality if not present, will build including JSON functionality if it is present.
The current vm_power_manager example app has the capability to accept power policies from virtual machines via virtio-serial channels. These power policies allow a virtual machine to give information to the power manager to allow the power manager take care of the power management of the virtual machine based on the information in the policy.
This power policy functionality is limited to virtual machines sending the policies to the power manager (which runs in the Host OS), and a solution was needed for additional methods of sending power policies to the power manager app.
The main use-case for this modification is for containers and host applications that wish to send polices to the power manager.
This patchset adds the capability to send power polices and power commands to the vm_power_manager app via JSON strings through a fifo on the file system.
For example, given the following file, policy.json:
{"policy": {
"name": "ubuntu2",
"command": "create",
"policy_type": "TIME",
"busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ],
"quiet_hours":[ 2, 3, 4, 5, 6 ],
"core_list":[ 11, 12, 13 ]
}}
Then running the command:
cat policy.json >/tmp/powermonitor/fifo.0
The policy is sent to the vm_power_manager. The power manager app then parses the JSON data, and inserts the policy into the array of policies.
Part of the patch series contains documentation updates to give all the details of the valid name-value pairs, the data types, etc.
[1/7] examples/power: add checks around hypervisor [2/7] lib/power: add changes for host commands/policies [3/7] examples/power: add necessary changes to guest app [4/7] examples/power: add host channel to power manager [5/7] examples/power: add json string handling [6/7] doc/vm_power_manager: add JSON interface API info [7/7] examples/power: add json example files
PATCH v2 1/7 examples/power: add checks around hypervisor
Allow vm_power_manager to run without requiring qemu to be present on the machine. This will be required for instances where the JSON interface is used for commands and polices, without any VMs present. A use case for this is a container enviromnent.
--- examples/vm_power_manager/channel_manager.c | 71 +++++++++++++-------- examples/vm_power_manager/channel_monitor.c | 2 +- 2 files changed, 44 insertions(+), 29 deletions(-)
examples/vm_power_manager/channel_manager.c +43 -28
@@ -43,7 +43,8 @@ static unsigned char *global_cpumaps;static virVcpuInfo *global_vircpuinfo;static size_t global_maplen; -static unsigned global_n_host_cpus; +static unsigned int global_n_host_cpus; +static bool global_hypervisor_available;/* * Represents a single Virtual Machine
@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) {struct virtual_machine_info *vm_info = (struct virtual_machine_info *)chan_info->priv_info; -return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); + +if (global_hypervisor_available && (vm_info !=NULL )) +return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); +else +return 0 ; } static inline int
@@ -559,6 +564,8 @@ get_all_vm(int *num_vm, int *num_vcpu)VIR_CONNECT_LIST_DOMAINS_PERSISTENT ;unsigned int domain_flag =VIR_DOMAIN_VCPU_CONFIG ; +if (!global_hypervisor_available) +return ;memset (global_cpumaps,0 ,CHANNEL_CMDS_MAX_CPUS *global_maplen);if (virNodeGetInfo (global_vir_conn_ptr, &node_info)) {
@@ -768,38 +775,42 @@ connect_hypervisor(const char *path) }return 0 ; } -int -channel_manager_init (const char *path) +channel_manager_init(const char *path __rte_unused) {virNodeInfo info;LIST_INIT (&vm_list_head);if (connect_hypervisor (path) <0 ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); -return -1 ; - } - - global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + global_n_host_cpus =64 ; + global_hypervisor_available =0 ; +RTE_LOG (INFO ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); + }else { + global_hypervisor_available =1 ; + + global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + + global_vircpuinfo =rte_zmalloc (NULL , +sizeof (*global_vircpuinfo) * +CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); +if (global_vircpuinfo ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); + goto error; + } + global_cpumaps =rte_zmalloc (NULL , +CHANNEL_CMDS_MAX_CPUS * global_maplen, +RTE_CACHE_LINE_SIZE ); +if (global_cpumaps ==NULL ) + goto error; - global_vircpuinfo =rte_zmalloc (NULL ,sizeof (*global_vircpuinfo) * -CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); -if (global_vircpuinfo ==NULL ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); - goto error; - } - global_cpumaps =rte_zmalloc (NULL ,CHANNEL_CMDS_MAX_CPUS * global_maplen, -RTE_CACHE_LINE_SIZE ); -if (global_cpumaps ==NULL ) { - goto error; +if (virNodeGetInfo (global_vir_conn_ptr, &info)) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); + goto error; + } + global_n_host_cpus = (unsigned int )info.cpus; } -if (virNodeGetInfo (global_vir_conn_ptr, &info)) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); - goto error; - } - global_n_host_cpus = (unsigned )info.cpus;if (global_n_host_cpus >CHANNEL_CMDS_MAX_CPUS ) { RTE_LOG(WARNING, CHANNEL_MANAGER, "The number of host CPUs(%u) exceeds the "
@@ -811,7 +822,8 @@ channel_manager_init(const char *path)return 0 ; error: -disconnect_hypervisor (); +if (global_hypervisor_available) +disconnect_hypervisor ();return -1 ; }
@@ -838,7 +850,10 @@ channel_manager_exit(void)rte_free (vm_info); } -rte_free (global_cpumaps); -rte_free (global_vircpuinfo); -disconnect_hypervisor (); +if (global_hypervisor_available) { +/* Only needed if hypervisor available */ +rte_free (global_cpumaps); +rte_free (global_vircpuinfo); +disconnect_hypervisor (); + } }
examples/vm_power_manager/channel_monitor.c +1 -1
@@ -66,7 +66,7 @@ static void core_share_status(int pNo) { -int noVms, noVcpus, z, x, t; +int noVms =0 , noVcpus =0 , z, x, t;get_all_vm (&noVms, &noVcpus);
Signature · 1 line
2.17.1
PATCH v2 2/7 lib/power: add changes for host commands/policies
In reply to David Hunt--- lib/librte_power/channel_commands.h | 5 +++++ 1 file changed, 5 insertions(+)
lib/librte_power/channel_commands.h +5 -0
@@ -19,6 +19,7 @@ extern "C" {#define CPU_POWER 1#define CPU_POWER_CONNECT 2#define PKT_POLICY 3 +#define PKT_POLICY_REMOVE 4/* CPU Power Command Scaling */ #define CPU_POWER_SCALE_UP 1
@@ -58,6 +59,9 @@ struct traffic {uint32_t max_max_packet_thresh; }; +#define CORE_TYPE_VIRTUAL 0 +#define CORE_TYPE_PHYSICAL 1 +struct channel_packet {uint64_t resource_id;/**< core_num, device */ uint32_t unit;/**< scale down/up/min/max */
@@ -70,6 +74,7 @@ struct channel_packet {uint8_t vcpu_to_control[MAX_VCPU_PER_VM ];uint8_t num_vcpu;struct timer_profile timer_policy; +bool core_type;enum workload workload;enum policy_to_use policy_to_use;struct t_boost_status t_boost_status;
Signature · 1 line
2.17.1
PATCH v2 3/7 examples/power: add necessary changes to guest app
In reply to David HuntThe changes here are minimal, as the guest app functionality is not changing at all, but there is a new element in the channel_packet struct that needs to have a default set (channel_packet->core_type).
--- examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 1 + 1 file changed, 1 insertion(+)
examples/vm_power_manager/guest_cli/vm_power_cli_guest.c +1 -0
@@ -92,6 +92,7 @@ set_policy_defaults(struct channel_packet *pkt) pkt->timer_policy.hours_to_use_traffic_profile[0 ] =8 ; pkt->timer_policy.hours_to_use_traffic_profile[1 ] =10 ; + pkt->core_type =VIRTUAL ; pkt->workload =LOW ; pkt->policy_to_use =TIME ; pkt->command =PKT_POLICY ;
Signature · 1 line
2.17.1
PATCH v2 4/7 examples/power: add host channel to power manager
In reply to David HuntThis patch adds a fifo channel to the vm_power_manager app through which we can send commands and polices. Intended for sending JSON strings. The fifo is at /tmp/powermonitor/fifo.0
--- examples/vm_power_manager/channel_manager.c | 108 +++++++++++++++ examples/vm_power_manager/channel_manager.h | 17 ++- examples/vm_power_manager/channel_monitor.c | 146 +++++++++++++++----- examples/vm_power_manager/main.c | 2 + 4 files changed, 238 insertions(+), 35 deletions(-)
examples/vm_power_manager/channel_manager.c +108 -0
@@ -13,6 +13,7 @@#include <sys/queue.h> #include <sys/types.h> +#include <sys/stat.h> #include <sys/socket.h> #include <sys/select.h>
@@ -284,6 +285,38 @@ open_non_blocking_channel(struct channel_info *info)return 0 ; } +static int +open_host_channel (struct channel_info *info) +{ +int flags; + + info->fd =open (info->channel_path,O_RDWR |O_RSYNC ); +if (info->fd ==-1 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error(%s) opening fifo for '%s'\n" , +strerror (errno), + info->channel_path); +return -1 ; + } + +/* Get current flags */ + flags =fcntl (info->fd,F_GETFL ,0 ); +if (flags <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER ,"Error(%s) fcntl get flags socket for" +"'%s'\n" ,strerror (errno), info->channel_path); +return 1 ; + } +/* Set to Non Blocking */ + flags |=O_NONBLOCK ; +if (fcntl (info->fd,F_SETFL , flags) <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER , +"Error(%s) setting non-blocking " +"socket for '%s'\n" , +strerror (errno), info->channel_path); +return -1 ; + } +return 0 ; +} +static int setup_channel_info (struct virtual_machine_info **vm_info_dptr,struct channel_info **chan_info_dptr,unsigned channel_num)
@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, chan_info->channel_num = channel_num; chan_info->priv_info = (void *)vm_info; chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_BINARY ;if (open_non_blocking_channel (chan_info) <0 ) { RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open channel: " "'%s' for VM '%s'\n",
@@ -316,6 +350,35 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr,return 0 ; } +static int +setup_host_channel_info (struct channel_info **chan_info_dptr, +unsigned int channel_num) +{ +struct channel_info *chan_info = *chan_info_dptr; + + chan_info->channel_num = channel_num; + chan_info->priv_info = (void *)0 ; + chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_JSON ; +sprintf (chan_info->channel_path,"%sfifo.0" ,CHANNEL_MGR_SOCKET_PATH ); + +if (open_host_channel (chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could not open host channel: " +"'%s'\n" , + chan_info->channel_path); +return -1 ; + } +if (add_channel_to_monitor (&chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could add channel: " +"'%s' to epoll ctl\n" , + chan_info->channel_path); +return -1 ; + + } + chan_info->status =CHANNEL_MGR_CHANNEL_CONNECTED ; +return 0 ; +} +int add_all_channels (const char *vm_name) {
@@ -470,6 +533,51 @@ add_channels(const char *vm_name, unsigned *channel_list,return num_channels_enabled; } +int +add_host_channel (void ) +{ +struct channel_info *chan_info; +char socket_path[PATH_MAX ]; +int num_channels_enabled =0 ; +int ret; + +snprintf (socket_path,sizeof (socket_path),"%sfifo.%u" , +CHANNEL_MGR_SOCKET_PATH ,0 ); + + errno =0 ; + ret =mkfifo (socket_path,0666 ); +if ((errno !=EEXIST ) && (ret <0 )) { +printf (" %d %d, %d\n" , ret,EEXIST , errno); +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Cannot create fifo '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + + errno =0 ; +if (access (socket_path,F_OK ) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Channel path '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + chan_info =rte_malloc (NULL ,sizeof (*chan_info), +RTE_CACHE_LINE_SIZE ); +if (chan_info ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for " +"channel '%s'\n" , socket_path); +return 0 ; + } +snprintf (chan_info->channel_path, +sizeof (chan_info->channel_path),"%sfifo.%u" , +CHANNEL_MGR_SOCKET_PATH ,0 ); +if (setup_host_channel_info (&chan_info,0 ) <0 ) { +rte_free (chan_info); +return 0 ; + } + num_channels_enabled++; + +return num_channels_enabled; +} +int remove_channel (struct channel_info **chan_info_dptr) {
examples/vm_power_manager/channel_manager.h +16 -1
@@ -37,7 +37,7 @@ struct sockaddr_un _sockaddr_un;#define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path)#endif -#define MAX_VMS 4 +#define MAX_VMS 64#define MAX_VCPUS 20
@@ -54,6 +54,11 @@ enum channel_status { CHANNEL_MGR_CHANNEL_DISCONNECTED = 0,CHANNEL_MGR_CHANNEL_DISABLED , CHANNEL_MGR_CHANNEL_PROCESSING}; +/* Communication Channel Type */ +enum channel_type {CHANNEL_TYPE_BINARY =0 , +CHANNEL_TYPE_INI , +CHANNEL_TYPE_JSON }; +/* VM libvirt(qemu/KVM) connection status */ enum vm_status {CHANNEL_MGR_VM_INACTIVE =0 ,CHANNEL_MGR_VM_ACTIVE };
@@ -66,6 +71,7 @@ struct channel_info {volatile uint32_t status;/**< Connection status(enum channel_status) */ int fd;/**< AF_UNIX socket fd */ unsigned channel_num;/**< CHANNEL_MGR_SOCKET_PATH/<vm_name>.channel_num */ +enum channel_type type;/**< Binary, ini, json, etc. */ void *priv_info;/**< Pointer to private info, do not modify */ };
@@ -226,6 +232,15 @@ int add_all_channels(const char *vm_name);int add_channels (const char *vm_name,unsigned *channel_list,unsigned num_channels); +/** +* Set up a fifo by which host applications can send command an policies +* through a fifo to the vm_power_manager +* +* @return +* - 0 for success +*/ +int add_host_channel (void ); +/** * Remove a channel definition from the channel manager. This must only be * called from the channel monitor thread.
examples/vm_power_manager/channel_monitor.c +112 -34
225 lines not on this page · raw message
examples/vm_power_manager/main.c +2 -0
@@ -421,6 +421,8 @@ main(int argc, char **argv)return -1 ; } +add_host_channel (); +printf ("Running core monitor on lcore id %d\n" , lcore_id);rte_eal_remote_launch (run_core_monitor,NULL , lcore_id);
Signature · 1 line
2.17.1
PATCH v2 5/7 examples/power: add json string handling
In reply to David HuntAdd JSON string handling to vm_power_manager for JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, the vm_power_manager user guide documentation updates.
This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
--- examples/vm_power_manager/Makefile | 6 + examples/vm_power_manager/channel_monitor.c | 297 +++++++++++++++++--- 2 files changed, 258 insertions(+), 45 deletions(-)
examples/vm_power_manager/Makefile +6 -0
@@ -31,6 +31,12 @@ CFLAGS += $(WERROR_FLAGS) LDLIBS += -lvirt +JANSSON := $(shell pkg-config --exists jansson; echo $$?) +ifeq ($(JANSSON), 0) +LDLIBS += $(shell pkg-config --libs jansson) +CFLAGS += -DUSE_JANSSON +endif + ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
examples/vm_power_manager/channel_monitor.c +252 -45
383 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v2 6/7 doc/vm_power_manager: add JSON interface API info
In reply to David Hunt--- .../sample_app_ug/vm_power_management.rst | 236 ++++++++++++++++++ 1 file changed, 236 insertions(+)
doc/guides/sample_app_ug/vm_power_management.rst +236 -0
@@ -337,6 +337,242 @@ monitoring of branch ratio on cores doing busy polling via PMDs. and will need to be adjusted for different workloads. + +JSON API +~~~~~~~~ + +In addition to the command line interface for host command and a virtio-serial +interface for VM power policies, there is also a JSON interface through which +power commands and policies can be sent. This functionality adds a dependency +on the Jansson library, and the Jansson development package must be installed +on the system before the JSON parsing functionality is included in the app. +This is achieved by: + + .. code-block:: console + + apt-get install libjansson-dev + +The command and package name may be different depending on your operating +system. It's worth noting that the app will successfully build without this +package present, but a warning is shown during compilation, and the JSON +parsing functionality will not be present in the app. + +Sending a command or policy to the power manager application is achieved by +simply opening a fifo file, writing a JSON string to that fifo, and closing +the file. + +The fifo is at /tmp/powermonitor/fifo.0 + +The jason string can be a policy or instruction, and takes the following +format: + + .. code-block:: console + + {"packet_type": { + "pair_1": value, + "pair_2": value + }} + +The 'packet_type' header can contain one of two values, depending on +whether a policy or power command is being sent. The two possible values are +"policy" and "instruction", and the expected name-value pairs is different +depending on which type is being sent. + +The pairs are the format of standard JSON name-value pairs. The value type +varies between the different name/value pairs, and may be intgers, strings, +arrays, etc. Examples of policies follow later in this document. The allowed +names and value types are as follows: + + +:Pair Name: "name" +:Description: Name of the VM or Host. Allows the parser to associate the + policy with the relevant VM or Host OS. +:Type: string +:Values: any valid string +:Required: yes +:Example: + + .. code-block:: console + + ""name", "ubuntu2" + + +:Pair Name: "command" +:Description: The type of packet we're sending to the power manager. We can be + creating or destroying a policy, or sending a direct command to adjust + the frequency of a core, similar to the command line interface. +:Type: string +:Values: + + :"CREATE": used when creating a new policy, + :"DESTROY": used when removing a policy, + :"POWER": used when sending an immediate command, max, min, etc. +:Required: yes +:Example: + + .. code-block:: console + + "command", "CREATE" + + +:Pair Name: "policy_type" +:Description: Type of policy to apply. Please see vm_power_manager documentation + for more information on the types of policies that may be used. +:Type: string +:Values: + + :"TIME": Time-of-day policy. Frequencies of the relevant cores are + scaled up/down depending on busy and quiet hours. + :"TRAFFIC": This policy takes statistics from the NIC and scales up + and down accordingly. + :"WORKLOAD": This policy looks at how heavily loaded the cores are, + and scales up and down accordingly. + :"BRANCH_RATIO": This out-of-band policy can look at the ratio between + branch hits and misses on a core, and is useful for detecting + how much packet processing a core is doing. +:Required: only for CREATE/DESTROY command +:Example: + + .. code-block:: console + + "policy_type", "TIME" + +:Pair Name: "busy_hours" +:Description: The hours of the day in which we scale up the cores for busy + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console + + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ] + +:Pair Name: "quiet_hours" +:Description: The hours of the day in which we scale down the cores for quiet + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console + + "quiet_hours":[ 2, 3, 4, 5, 6 ] + +:Pair Name: "avg_packet_thresh" +:Description: Threshold below which the frequency will be set to min for + the TRAFFIC policy. If the traffic rate is above this and below max, the + frequency will be set to medium. +:Type: integer +:Values: The number of packets below which the TRAFFIC policy applies the + minimum frequency, or medium frequency if between avg and max thresholds. +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: console + + "avg_packet_thresh": 100000 + +:Pair Name: "max_packet_thresh" +:Description: Threshold above which the frequency will be set to max for + the TRAFFIC policy +:Type: integer +:Values: The number of packets per interval above which the TRAFFIC policy + applies the maximum frequency +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: console + + "max_packet_thresh": 500000 + +:Pair Name: "core_list" +:Description: The cores to which to apply the policy. +:Type: array of integers +:Values: array with list of virtual CPUs. +:Required: only policy CREATE/DESTROY +:Example: + + .. code-block:: console + + "core_list":[ 10, 11 ] + +:Pair Name: "unit" +:Description: the type of power operation to apply in the command +:Type: string +:Values: + + :"SCALE_MAX": Scale frequency of this core to maximum + :"SCALE_MIN": Scale frequency of this core to minimum + :"SCALE_UP": Scale up frequency of this core + :"SCALE_DOWN": Scale down frequency of this core + :"ENABLE_TURBO": Enable Turbo Boost for this core + :"DISABLE_TURBO": Disable Turbo Boost for this core +:Required: only for POWER instruction +:Example: + + .. code-block:: console + + "unit", "SCALE_MAX" + +:Pair Name: "resource_id" +:Description: The core to which to apply the power command. +:Type: integer +:Values: valid core id for VM or host OS. +:Required: only POWER instruction +:Example: + + .. code-block:: console + + "resource_id": 10 + +JSON API Examples +~~~~~~~~~~~~~~~~~ + +Profile create example: + + .. code-block:: console + + {"policy": { + "name": "ubuntu", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11 ] + }} + +Profile destroy example: + + .. code-block:: console + + {"profile": { + "name": "ubuntu", + "command": "destroy", + }} + +Power command example: + + .. code-block:: console + + {"command": { + "name": "ubuntu", + "unit": "SCALE_MAX", + "resource_id": 10 + }} + +To send a JSON string to the Power Manager application, simply paste the +example JSON string into a text file and cat it into the fifo: + + .. code-block:: console + + cat file.json >/tmp/powermonitor/fifo.0 + +The console of the Power Manager application should indicate the command that +was just received via the fifo. + Compiling and Running the Guest Applications --------------------------------------------
Signature · 1 line
2.17.1
PATCH v2 7/7 examples/power: add json example files
In reply to David HuntThis patch provides some example files in the json_examples sub-directory for sending to the fifo.
--- examples/vm_power_manager/json_examples/README | 6 ++++++ examples/vm_power_manager/json_examples/create.json | 8 ++++++++ examples/vm_power_manager/json_examples/destroy.json | 4 ++++ examples/vm_power_manager/json_examples/set_core_max.json | 6 ++++++ examples/vm_power_manager/json_examples/set_core_min.json | 6 ++++++ 5 files changed, 30 insertions(+) create mode 100644 examples/vm_power_manager/json_examples/README create mode 100644 examples/vm_power_manager/json_examples/create.json create mode 100644 examples/vm_power_manager/json_examples/destroy.json create mode 100644 examples/vm_power_manager/json_examples/set_core_max.json create mode 100644 examples/vm_power_manager/json_examples/set_core_min.json
examples/vm_power_manager/json_examples/README new file +6 -0
@@ -0,0 +1,6 @@ +Sample files for sending to the vm_power_manager through the fifo. + +Simply cat the file to /tmp/powermonitor/fifo.0 when the vm_power_manager +application is running. + +E.g. cat create.json >/tmp/powermonitor/fifo.0
examples/vm_power_manager/json_examples/create.json new file +8 -0
@@ -0,0 +1,8 @@ +{"policy": { + "name": "policy-1", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11, 12 ] +}}
examples/vm_power_manager/json_examples/destroy.json new file +4 -0
@@ -0,0 +1,4 @@ +{"policy": { + "name": "policy-1", + "command": "destroy" +}}
examples/vm_power_manager/json_examples/set_core_max.json new file +6 -0
@@ -0,0 +1,6 @@ +{"instruction": { + "name": "set_power", + "command": "power", + "unit": "SCALE_MAX", + "resource_id": 10 +}}
examples/vm_power_manager/json_examples/set_core_min.json new file +6 -0
@@ -0,0 +1,6 @@ +{"instruction": { + "name": "set_power", + "command": "power", + "unit": "SCALE_MIN", + "resource_id": 10 +}}
Signature · 1 line
2.17.1
v3 cover add json power policy interface for containers
In reply to David HuntThe current vm_power_manager example app has the capability to accept power policies from virtual machines via virtio-serial channels. These power policies allow a virtual machine to give information to the power manager to allow the power manager take care of the power management of the virtual machine based on the information in the policy.
This power policy functionality is limited to virtual machines sending the policies to the power manager (which runs in the Host OS), and a solution was needed for additional methods of sending power policies to the power manager app.
The main use-case for this modification is for containers and host applications that wish to send polices to the power manager.
This patchset adds the capability to send power polices and power commands to the vm_power_manager app via JSON strings through a fifo on the file system.
For example, given the following file, policy.json:
{"policy": {
"name": "ubuntu2",
"command": "create",
"policy_type": "TIME",
"busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ],
"quiet_hours":[ 2, 3, 4, 5, 6 ],
"core_list":[ 11, 12, 13 ]
}}
Then running the command:
cat policy.json >/tmp/powermonitor/fifo.0
The policy is sent to the vm_power_manager. The power manager app then parses the JSON data, and inserts the policy into the array of policies.
Part of the patch series contains documentation updates to give all the details of the valid name-value pairs, the data types, etc.
Patch v2:
* Fixed review comments from Stephen Hemminger and Lei A Yao.
* Added a check in the Makefile for libjansson-dev. Will Warn user and build without JSON functionality if not present, will build including JSON functionality if it is present.
Patch v3:
* Added meson/ninja support for vm_power_manager and guest_cli apps
* Fixed compilation issue with guest_cli app
[1/8] examples/power: add checks around hypervisor [2/8] lib/power: add changes for host commands/policies [3/8] examples/power: add necessary changes to guest app [4/8] examples/power: add host channel to power manager [5/8] examples/power: add json string handling [6/8] examples/power: add meson/ninja build support [7/8] doc/vm_power_manager: add JSON interface API info [8/8] examples/power: add json example files
PATCH v3 1/8 examples/power: add checks around hypervisor
Allow vm_power_manager to run without requiring qemu to be present on the machine. This will be required for instances where the JSON interface is used for commands and polices, without any VMs present. A use case for this is a container enviromnent.
--- examples/vm_power_manager/channel_manager.c | 71 +++++++++++++-------- examples/vm_power_manager/channel_monitor.c | 2 +- 2 files changed, 44 insertions(+), 29 deletions(-)
examples/vm_power_manager/channel_manager.c +43 -28
@@ -43,7 +43,8 @@ static unsigned char *global_cpumaps;static virVcpuInfo *global_vircpuinfo;static size_t global_maplen; -static unsigned global_n_host_cpus; +static unsigned int global_n_host_cpus; +static bool global_hypervisor_available;/* * Represents a single Virtual Machine
@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) {struct virtual_machine_info *vm_info = (struct virtual_machine_info *)chan_info->priv_info; -return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); + +if (global_hypervisor_available && (vm_info !=NULL )) +return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); +else +return 0 ; } static inline int
@@ -559,6 +564,8 @@ get_all_vm(int *num_vm, int *num_vcpu)VIR_CONNECT_LIST_DOMAINS_PERSISTENT ;unsigned int domain_flag =VIR_DOMAIN_VCPU_CONFIG ; +if (!global_hypervisor_available) +return ;memset (global_cpumaps,0 ,CHANNEL_CMDS_MAX_CPUS *global_maplen);if (virNodeGetInfo (global_vir_conn_ptr, &node_info)) {
@@ -768,38 +775,42 @@ connect_hypervisor(const char *path) }return 0 ; } -int -channel_manager_init (const char *path) +channel_manager_init(const char *path __rte_unused) {virNodeInfo info;LIST_INIT (&vm_list_head);if (connect_hypervisor (path) <0 ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); -return -1 ; - } - - global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + global_n_host_cpus =64 ; + global_hypervisor_available =0 ; +RTE_LOG (INFO ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); + }else { + global_hypervisor_available =1 ; + + global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + + global_vircpuinfo =rte_zmalloc (NULL , +sizeof (*global_vircpuinfo) * +CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); +if (global_vircpuinfo ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); + goto error; + } + global_cpumaps =rte_zmalloc (NULL , +CHANNEL_CMDS_MAX_CPUS * global_maplen, +RTE_CACHE_LINE_SIZE ); +if (global_cpumaps ==NULL ) + goto error; - global_vircpuinfo =rte_zmalloc (NULL ,sizeof (*global_vircpuinfo) * -CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); -if (global_vircpuinfo ==NULL ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); - goto error; - } - global_cpumaps =rte_zmalloc (NULL ,CHANNEL_CMDS_MAX_CPUS * global_maplen, -RTE_CACHE_LINE_SIZE ); -if (global_cpumaps ==NULL ) { - goto error; +if (virNodeGetInfo (global_vir_conn_ptr, &info)) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); + goto error; + } + global_n_host_cpus = (unsigned int )info.cpus; } -if (virNodeGetInfo (global_vir_conn_ptr, &info)) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); - goto error; - } - global_n_host_cpus = (unsigned )info.cpus;if (global_n_host_cpus >CHANNEL_CMDS_MAX_CPUS ) { RTE_LOG(WARNING, CHANNEL_MANAGER, "The number of host CPUs(%u) exceeds the "
@@ -811,7 +822,8 @@ channel_manager_init(const char *path)return 0 ; error: -disconnect_hypervisor (); +if (global_hypervisor_available) +disconnect_hypervisor ();return -1 ; }
@@ -838,7 +850,10 @@ channel_manager_exit(void)rte_free (vm_info); } -rte_free (global_cpumaps); -rte_free (global_vircpuinfo); -disconnect_hypervisor (); +if (global_hypervisor_available) { +/* Only needed if hypervisor available */ +rte_free (global_cpumaps); +rte_free (global_vircpuinfo); +disconnect_hypervisor (); + } }
examples/vm_power_manager/channel_monitor.c +1 -1
@@ -66,7 +66,7 @@ static void core_share_status(int pNo) { -int noVms, noVcpus, z, x, t; +int noVms =0 , noVcpus =0 , z, x, t;get_all_vm (&noVms, &noVcpus);
Signature · 1 line
2.17.1
Re: [PATCH v3 1/8] examples/power: add checks around hypervisor
Quoted 7 lines · David Hunt
Allow
vm_power_managerto run without requiring qemu to be present on the machine. This will be required for instances where the JSON interface is used for commands and polices, without any VMs present. A use case for this is a container enviromnent.Signed-off-by David Hunt <[email protected]>---
<snip>
examples/vm_power_manager/channel_monitor.c static void · line 70
Quoted 9 lines
examples/vm_power_manager/channel_monitor.c +1
-1@@ -66,7 +66,7 @@ static void core_share_status(int pNo) { -int noVms, noVcpus, z, x, t; +int noVms =0 , noVcpus =0 , z, x, t;
This looks like a unrelated change?
Quoted 3 lines
examples/vm_power_manager/channel_monitor.c +0
-0get_all_vm (&noVms, &noVcpus);
Signature · 2 lines
Thanks, Anatoly
Re: [PATCH v3 1/8] examples/power: add checks around hypervisor
Quoted 11 lines · Anatoly
Quoted 7 lines · David Hunt
Allow
vm_power_managerto run without requiring qemu to be present on the machine. This will be required for instances where the JSON interface is used for commands and polices, without any VMs present. A use case for this is a container enviromnent.Signed-off-by David Hunt <[email protected]>---
<snip>
Quoted 14 lines
examples/vm_power_manager/channel_monitor.c static void · line 69
Quoted 7 lines
examples/vm_power_manager/channel_monitor.c +1
-0@@ -66,7 +66,7 @@ static void core_share_status(int pNo) { - int noVms, noVcpus, z, x, t; + int noVms = 0, noVcpus = 0, z, x, t;This looks like a unrelated change?
Quoted 2 lines
examples/vm_power_manager/channel_monitor.c +0
-0get_all_vm(&noVms, &noVcpus);
I'll move it to a separate commit in the next version.
Thanks,
Dave.
PATCH v3 2/8 lib/power: add changes for host commands/policies
In reply to David Hunt--- lib/librte_power/channel_commands.h | 5 +++++ 1 file changed, 5 insertions(+)
lib/librte_power/channel_commands.h +5 -0
@@ -19,6 +19,7 @@ extern "C" {#define CPU_POWER 1#define CPU_POWER_CONNECT 2#define PKT_POLICY 3 +#define PKT_POLICY_REMOVE 4/* CPU Power Command Scaling */ #define CPU_POWER_SCALE_UP 1
@@ -58,6 +59,9 @@ struct traffic {uint32_t max_max_packet_thresh; }; +#define CORE_TYPE_VIRTUAL 0 +#define CORE_TYPE_PHYSICAL 1 +struct channel_packet {uint64_t resource_id;/**< core_num, device */ uint32_t unit;/**< scale down/up/min/max */
@@ -70,6 +74,7 @@ struct channel_packet {uint8_t vcpu_to_control[MAX_VCPU_PER_VM ];uint8_t num_vcpu;struct timer_profile timer_policy; +bool core_type;enum workload workload;enum policy_to_use policy_to_use;struct t_boost_status t_boost_status;
Signature · 1 line
2.17.1
Re: [PATCH v3 2/8] lib/power: add changes for host commands/policies
Quoted 1 line · David Hunt
Signed-off-by David Hunt <[email protected]>
The commit message is not very descriptive as to what these chages are and why they are added.
Signature · 2 lines
Thanks, Anatoly
Re: [PATCH v3 2/8] lib/power: add changes for host commands/policies
Quoted 5 lines · Anatoly
Quoted 1 line · David Hunt
Signed-off-by David Hunt <[email protected]>The commit message is not very descriptive as to what these chages are and why they are added.
Sure, I'll add a more descriptive comment next version.
Thanks,
Dave.
PATCH v3 3/8 examples/power: add necessary changes to guest app
In reply to David HuntThe changes here are minimal, as the guest app functionality is not changing at all, but there is a new element in the channel_packet struct that needs to have a default set (channel_packet->core_type).
--- examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 1 + 1 file changed, 1 insertion(+)
examples/vm_power_manager/guest_cli/vm_power_cli_guest.c +1 -0
@@ -92,6 +92,7 @@ set_policy_defaults(struct channel_packet *pkt) pkt->timer_policy.hours_to_use_traffic_profile[0 ] =8 ; pkt->timer_policy.hours_to_use_traffic_profile[1 ] =10 ; + pkt->core_type =CORE_TYPE_VIRTUAL ; pkt->workload =LOW ; pkt->policy_to_use =TIME ; pkt->command =PKT_POLICY ;
Signature · 1 line
2.17.1
Re: [PATCH v3 3/8] examples/power: add necessary changes to guest app
Quoted 6 lines · David Hunt
The changes here are minimal, as the guest app functionality is not changing at all, but there is a new element in the
channel_packetstruct that needs to have a default set (channel_packet->core_type).Signed-off-by David Hunt <[email protected]>---
Signature · 2 lines
Thanks, Anatoly
PATCH v3 4/8 examples/power: add host channel to power manager
In reply to David HuntThis patch adds a fifo channel to the vm_power_manager app through which we can send commands and polices. Intended for sending JSON strings. The fifo is at /tmp/powermonitor/fifo.0
--- examples/vm_power_manager/channel_manager.c | 108 +++++++++++++++ examples/vm_power_manager/channel_manager.h | 17 ++- examples/vm_power_manager/channel_monitor.c | 146 +++++++++++++++----- examples/vm_power_manager/main.c | 2 + 4 files changed, 238 insertions(+), 35 deletions(-)
examples/vm_power_manager/channel_manager.c +108 -0
@@ -13,6 +13,7 @@#include <sys/queue.h> #include <sys/types.h> +#include <sys/stat.h> #include <sys/socket.h> #include <sys/select.h>
@@ -284,6 +285,38 @@ open_non_blocking_channel(struct channel_info *info)return 0 ; } +static int +open_host_channel (struct channel_info *info) +{ +int flags; + + info->fd =open (info->channel_path,O_RDWR |O_RSYNC ); +if (info->fd ==-1 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error(%s) opening fifo for '%s'\n" , +strerror (errno), + info->channel_path); +return -1 ; + } + +/* Get current flags */ + flags =fcntl (info->fd,F_GETFL ,0 ); +if (flags <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER ,"Error(%s) fcntl get flags socket for" +"'%s'\n" ,strerror (errno), info->channel_path); +return 1 ; + } +/* Set to Non Blocking */ + flags |=O_NONBLOCK ; +if (fcntl (info->fd,F_SETFL , flags) <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER , +"Error(%s) setting non-blocking " +"socket for '%s'\n" , +strerror (errno), info->channel_path); +return -1 ; + } +return 0 ; +} +static int setup_channel_info (struct virtual_machine_info **vm_info_dptr,struct channel_info **chan_info_dptr,unsigned channel_num)
@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, chan_info->channel_num = channel_num; chan_info->priv_info = (void *)vm_info; chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_BINARY ;if (open_non_blocking_channel (chan_info) <0 ) { RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open channel: " "'%s' for VM '%s'\n",
@@ -316,6 +350,35 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr,return 0 ; } +static int +setup_host_channel_info (struct channel_info **chan_info_dptr, +unsigned int channel_num) +{ +struct channel_info *chan_info = *chan_info_dptr; + + chan_info->channel_num = channel_num; + chan_info->priv_info = (void *)0 ; + chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_JSON ; +sprintf (chan_info->channel_path,"%sfifo.0" ,CHANNEL_MGR_SOCKET_PATH ); + +if (open_host_channel (chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could not open host channel: " +"'%s'\n" , + chan_info->channel_path); +return -1 ; + } +if (add_channel_to_monitor (&chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could add channel: " +"'%s' to epoll ctl\n" , + chan_info->channel_path); +return -1 ; + + } + chan_info->status =CHANNEL_MGR_CHANNEL_CONNECTED ; +return 0 ; +} +int add_all_channels (const char *vm_name) {
@@ -470,6 +533,51 @@ add_channels(const char *vm_name, unsigned *channel_list,return num_channels_enabled; } +int +add_host_channel (void ) +{ +struct channel_info *chan_info; +char socket_path[PATH_MAX ]; +int num_channels_enabled =0 ; +int ret; + +snprintf (socket_path,sizeof (socket_path),"%sfifo.%u" , +CHANNEL_MGR_SOCKET_PATH ,0 ); + + errno =0 ; + ret =mkfifo (socket_path,0666 ); +if ((errno !=EEXIST ) && (ret <0 )) { +printf (" %d %d, %d\n" , ret,EEXIST , errno); +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Cannot create fifo '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + + errno =0 ; +if (access (socket_path,F_OK ) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Channel path '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + chan_info =rte_malloc (NULL ,sizeof (*chan_info), +RTE_CACHE_LINE_SIZE ); +if (chan_info ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for " +"channel '%s'\n" , socket_path); +return 0 ; + } +snprintf (chan_info->channel_path, +sizeof (chan_info->channel_path),"%sfifo.%u" , +CHANNEL_MGR_SOCKET_PATH ,0 ); +if (setup_host_channel_info (&chan_info,0 ) <0 ) { +rte_free (chan_info); +return 0 ; + } + num_channels_enabled++; + +return num_channels_enabled; +} +int remove_channel (struct channel_info **chan_info_dptr) {
examples/vm_power_manager/channel_manager.h +16 -1
@@ -37,7 +37,7 @@ struct sockaddr_un _sockaddr_un;#define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path)#endif -#define MAX_VMS 4 +#define MAX_VMS 64#define MAX_VCPUS 20
@@ -54,6 +54,11 @@ enum channel_status { CHANNEL_MGR_CHANNEL_DISCONNECTED = 0,CHANNEL_MGR_CHANNEL_DISABLED , CHANNEL_MGR_CHANNEL_PROCESSING}; +/* Communication Channel Type */ +enum channel_type {CHANNEL_TYPE_BINARY =0 , +CHANNEL_TYPE_INI , +CHANNEL_TYPE_JSON }; +/* VM libvirt(qemu/KVM) connection status */ enum vm_status {CHANNEL_MGR_VM_INACTIVE =0 ,CHANNEL_MGR_VM_ACTIVE };
@@ -66,6 +71,7 @@ struct channel_info {volatile uint32_t status;/**< Connection status(enum channel_status) */ int fd;/**< AF_UNIX socket fd */ unsigned channel_num;/**< CHANNEL_MGR_SOCKET_PATH/<vm_name>.channel_num */ +enum channel_type type;/**< Binary, ini, json, etc. */ void *priv_info;/**< Pointer to private info, do not modify */ };
@@ -226,6 +232,15 @@ int add_all_channels(const char *vm_name);int add_channels (const char *vm_name,unsigned *channel_list,unsigned num_channels); +/** +* Set up a fifo by which host applications can send command an policies +* through a fifo to the vm_power_manager +* +* @return +* - 0 for success +*/ +int add_host_channel (void ); +/** * Remove a channel definition from the channel manager. This must only be * called from the channel monitor thread.
examples/vm_power_manager/channel_monitor.c +112 -34
225 lines not on this page · raw message
examples/vm_power_manager/main.c +2 -0
@@ -421,6 +421,8 @@ main(int argc, char **argv)return -1 ; } +add_host_channel (); +printf ("Running core monitor on lcore id %d\n" , lcore_id);rte_eal_remote_launch (run_core_monitor,NULL , lcore_id);
Signature · 1 line
2.17.1
Re: [PATCH v3 4/8] examples/power: add host channel to power manager
Quoted 6 lines · David Hunt
This patch adds a fifo channel to the
vm_power_managerapp through which we can send commands and polices. Intended for sending JSON strings. The fifo is at/tmp/powermonitor/fifo.0Signed-off-by David Hunt <[email protected]>---
A bunch of nitpick comments below :)
Quoted 6 lines
examples/vm_power_manager/channel_manager.c | 108 +++++++++++++++ examples/vm_power_manager/channel_manager.h | 17 ++- examples/vm_power_manager/channel_monitor.c | 146 +++++++++++++++----- examples/vm_power_manager/main.c | 2 + 4 files changed, 238 insertions(+), 35 deletions(-)
<snip>
examples/vm_power_manager/channel_manager.c open_non_blocking_channel(struct channel_info *info) · line 319
Quoted 8 lines
examples/vm_power_manager/channel_manager.c +8
-0+"Error(%s) setting non-blocking " +"socket for '%s'\n" , + strerror(errno), info->channel_path); +return -1 ; + } +return 0 ; +} +
As far as i can tell, vm power manager is a proper DPDK application, meaning there can technically be several of these running independently under different prefixes. Hardcoded paths are OK, but you probably need to place a write-lock on a file to prevent another VM power manager from (accidentally) taking over the FIFO? Init would probably fail earlier, but you never know :)
Quoted 13 lines
static int
setup_channel_info(structvirtual_machine_info**vm_info_dptr,
structchannel_info**chan_info_dptr, unsignedchannel_num)examples/vm_power_manager/channel_manager.c +1
-0@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, chan_info->channel_num = channel_num; chan_info->priv_info = (void *)vm_info; chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_BINARY ;if (open_non_blocking_channel (chan_info) <0 ) { RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open channel: " "'%s' for VM '%s'\n",@@ -316,6 +350,35 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr,return 0 ;
examples/vm_power_manager/channel_manager.c setup_channel_info(struct virtual_machine_info **vm_info_dptr, · line 360
Quoted 10 lines
examples/vm_power_manager/channel_manager.c +8
-0} +static int +setup_host_channel_info (struct channel_info **chan_info_dptr, +unsigned int channel_num) +{ +struct channel_info *chan_info = *chan_info_dptr; + + chan_info->channel_num = channel_num; + chan_info->priv_info = (void *)0 ;
NULL?
examples/vm_power_manager/channel_manager.c setup_channel_info(struct virtual_machine_info **vm_info_dptr, · line 363
Quoted 3 lines
examples/vm_power_manager/channel_manager.c +3
-0+ chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_JSON ; +sprintf (chan_info->channel_path,"%sfifo.0" ,CHANNEL_MGR_SOCKET_PATH );
Here, 0 is part of the format string...
Quoted 7 lines
examples/vm_power_manager/channel_manager.c +7
-0+ +if (open_host_channel (chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could not open host channel: " +"'%s'\n" , + chan_info->channel_path); +return -1 ; + }
<snip>
examples/vm_power_manager/channel_manager.c add_channels(const char *vm_name, unsigned *channel_list, · line 545
Quoted 10 lines
examples/vm_power_manager/channel_manager.c +10
-0+int +add_host_channel (void ) +{ +struct channel_info *chan_info; +char socket_path[PATH_MAX ]; +int num_channels_enabled =0 ; +int ret; + +snprintf (socket_path,sizeof (socket_path),"%sfifo.%u" , +CHANNEL_MGR_SOCKET_PATH ,0 );
...while here, it's an argument. What's the significance of 0 in this context? Also, maybe better to put it in a function, so as to only have one place to fix if anything changes, instead of two?
examples/vm_power_manager/channel_manager.c add_channels(const char *vm_name, unsigned *channel_list, · line 548
Quoted 3 lines
examples/vm_power_manager/channel_manager.c +3
-0+ + errno =0 ; + ret =mkfifo (socket_path,0666 );
0666 seems like overly permissive to me?
examples/vm_power_manager/channel_manager.c add_channels(const char *vm_name, unsigned *channel_list, · line 550
Quoted 2 lines
examples/vm_power_manager/channel_manager.c +2
-0+if ((errno !=EEXIST ) && (ret <0 )) { +printf (" %d %d, %d\n" , ret,EEXIST , errno);
This looks like a leftover debug printf?
Also, maybe if (ret < 0 && errno != EEXIST)? I don't think there's a need to set errno beforehand here.
examples/vm_power_manager/channel_manager.c add_channels(const char *vm_name, unsigned *channel_list, · line 556
Quoted 6 lines
examples/vm_power_manager/channel_manager.c +6
-0+RTE_LOG (ERR ,CHANNEL_MANAGER ,"Cannot create fifo '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + + errno =0 ;
...and here too - if access() call failed, does it not always set errno value?
examples/vm_power_manager/channel_manager.c add_channels(const char *vm_name, unsigned *channel_list, · line 563
Quoted 7 lines
examples/vm_power_manager/channel_manager.c +7
-0+if (access (socket_path,F_OK ) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Channel path '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + chan_info =rte_malloc (NULL ,sizeof (*chan_info), +RTE_CACHE_LINE_SIZE );
0 alignment is equivalent to RTE_CACHE_LINE_SIZE, so no need to specify it explicitly.
examples/vm_power_manager/channel_manager.c add_channels(const char *vm_name, unsigned *channel_list, · line 571
Quoted 8 lines
examples/vm_power_manager/channel_manager.c +8
-0+if (chan_info ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for " +"channel '%s'\n" , socket_path); +return 0 ; + } +snprintf (chan_info->channel_path, +sizeof (chan_info->channel_path),"%sfifo.%u" , +CHANNEL_MGR_SOCKET_PATH ,0 );
Creating FIFO path again. Definitely needs a function :)
Quoted 17 lines
examples/vm_power_manager/channel_manager.c +9
-0+if (setup_host_channel_info (&chan_info,0 ) <0 ) { +rte_free (chan_info); +return 0 ; + } + num_channels_enabled++; + +return num_channels_enabled; +} +int remove_channel (struct channel_info **chan_info_dptr) {examples/vm_power_manager/channel_manager.h +0
-0
examples/vm_power_manager/channel_manager.h struct sockaddr_un _sockaddr_un; · line 40
Quoted 5 lines
examples/vm_power_manager/channel_manager.h +1
-1@@ -37,7 +37,7 @@ struct sockaddr_un _sockaddr_un;#define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path)#endif -#define MAX_VMS 4 +#define MAX_VMS 64
This change probably needs to be called out in commit message and explained. Or broken into a separate commit? Also, i think technically "MAX_VMS" is a bad name now that you're supporting containers as well as VM's. MAX_CLIENTS maybe?
examples/vm_power_manager/channel_manager.h enum channel_status { CHANNEL_MGR_CHANNEL_DISCONNECTED = 0, · line 58
Quoted 9 lines
examples/vm_power_manager/channel_manager.h +2
-0#define MAX_VCPUS 20@@ -54,6 +54,11 @@ enum channel_status { CHANNEL_MGR_CHANNEL_DISCONNECTED = 0,CHANNEL_MGR_CHANNEL_DISABLED , CHANNEL_MGR_CHANNEL_PROCESSING}; +/* Communication Channel Type */ +enum channel_type { CHANNEL_TYPE_BINARY = 0,
Should probably start values on a new line?
Quoted 8 lines
examples/vm_power_manager/channel_manager.h +3
-0+CHANNEL_TYPE_INI , + CHANNEL_TYPE_JSON}; +/* VM libvirt(qemu/KVM) connection status */ enum vm_status {CHANNEL_MGR_VM_INACTIVE =0 ,CHANNEL_MGR_VM_ACTIVE };@@ -66,6 +71,7 @@ struct channel_info {volatile uint32_t status;/**< Connection status(enum channel_status) */
<snip>
Quoted 5 lines
examples/vm_power_manager/channel_manager.h +2
-3- pol->core_share[count].pcpu = pcpu; -printf ("Monitoring pcpu %d\n" , pcpu); - } +RTE_LOG (INFO ,CHANNEL_MONITOR , +"Looking for pcpu for %s\n" , pol->pkt.vm_name);
examples/vm_power_manager/channel_manager.h
Quoted 10 lines
examples/vm_power_manager/channel_manager.h +10
-0+ +/* +* So now that we're handling virtual and physical cores, we need to +* differenciate between them when adding them to the branch monitor. +* Virtual cores need to be converted to physical cores. +*/ + + + +
Needs moar newlines :)
Quoted 7 lines
examples/vm_power_manager/channel_manager.h +7
-0+if (pol->pkt.core_type ==CORE_TYPE_VIRTUAL ) { +/* +* If the cores in the policy are virtual, we need to map them +* to physical core. We look up the vm info and use that for +* the mapping. +*/ +get_info_vm (pol->pkt.vm_name, &info);
<snip>
Quoted 4 lines
examples/vm_power_manager/channel_manager.h +0
-0@@ -362,10 +425,12 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info)if (pkt->command ==CPU_POWER ) { core_mask =get_pcpus_mask (chan_info, pkt->resource_id);if (core_mask ==0 ) {
examples/vm_power_manager/channel_manager.h process_request(struct channel_packet *pkt, struct channel_info *chan_info) · line 433
Quoted 10 lines
examples/vm_power_manager/channel_manager.h +6
-4-RTE_LOG (ERR ,CHANNEL_MONITOR ,"Error get physical CPU mask for " -"channel '%s' using vCPU(%u)\n" , chan_info->channel_path, - (unsigned )pkt->unit); -return -1 ; +/* +* Core mask will be 0 in the case where +* hypervisor is not available so we're working in +* the host, so use the core as the mask. +*/ + core_mask =1 << pkt->resource_id;
1ULL?
Signature · 2 lines
Thanks, Anatoly
Re: [PATCH v3 4/8] examples/power: add host channel to power manager
Hi Anatoly,
Quoted 19 lines · Anatoly
Quoted 6 lines · David Hunt
This patch adds a fifo channel to the
vm_power_managerapp through which we can send commands and polices. Intended for sending JSON strings. The fifo is at/tmp/powermonitor/fifo.0Signed-off-by David Hunt <[email protected]>---
A bunch of nitpick comments below :)
Quoted 6 lines
examples/vm_power_manager/channel_manager.c| 108 +++++++++++++++examples/vm_power_manager/channel_manager.h| 17 ++-examples/vm_power_manager/channel_monitor.c| 146 +++++++++++++++----- examples/vm_power_manager/main.c | 2 +4 files changed, 238 insertions(+), 35 deletions(-)<snip>
Quoted 10 lines
Review
Quoted 8 lines
+ "Error(%s) setting non-blocking " + "socket for '%s'\n",
+ strerror(errno),info->channel_path); + return -1;
+ }
+ return 0;(quoted diff) +2
-0+} +As far as i can tell, vm power manager is a proper DPDK application, meaning there can technically be several of these running independently under different prefixes. Hardcoded paths are OK, but you probably need to place a write-lock on a file to prevent another VM power manager from (accidentally) taking over the FIFO? Init would probably fail earlier, but you never know :)
vm_power_manager is only expected to be a single instance looking after the power across all cores in a system, so we do not expect multiple instance of this to be running.
Quoted 19 lines
Quoted 19 lines
static int
setup_channel_info(structvirtual_machine_info**vm_info_dptr, structchannel_info**chan_info_dptr, unsignedchannel_num)examples/vm_power_manager/channel_manager.c +1
-0@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, chan_info->channel_num = channel_num; chan_info->priv_info = (void *)vm_info; chan_info->status = CHANNEL_MGR_CHANNEL_DISCONNECTED; + chan_info->type = CHANNEL_TYPE_BINARY; if (open_non_blocking_channel(chan_info) < 0) {RTE_LOG(ERR,
CHANNEL_MANAGER, "Could not open channel: " "'%s' for VM '%s'\n",examples/vm_power_manager/channel_manager.c +0
-0@@ -316,6 +350,35 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, return 0; }+static int
+setup_host_channel_info(structchannel_info**chan_info_dptr,
Quoted 9 lines
examples/vm_power_manager/channel_manager.c setup_channel_info(struct virtual_machine_info **vm_info_dptr, · line 360
Quoted 6 lines
+ unsigned int
channel_num)examples/vm_power_manager/channel_manager.c +5
-0+{ + struct channel_info *chan_info = *chan_info_dptr; + + chan_info->channel_num = channel_num; + chan_info->priv_info = (void *)0;NULL?
Fixed in next version.
Quoted 17 lines
Quoted 4 lines
+
chan_info->status=CHANNEL_MGR_CHANNEL_DISCONNECTED; +chan_info->type=CHANNEL_TYPE_JSON;
+sprintf(chan_info->channel_path, "%sfifo.0", CHANNEL_MGR_SOCKET_PATH);Here, 0 is part of the format string...
Quoted 7 lines
+
+ if (open_host_channel(chan_info)< 0) {
+ RTE_LOG(ERR,CHANNEL_MANAGER, "Could not open host channel: " + "'%s'\n",
+chan_info->channel_path);
+ return -1;
+ }<snip>
Quoted 13 lines
examples/vm_power_manager/channel_manager.c add_channels(const char *vm_name, unsigned *channel_list, · line 545
Quoted 10 lines
examples/vm_power_manager/channel_manager.c +10
-0+int +add_host_channel (void ) +{ + struct channel_info *chan_info; + char socket_path[PATH_MAX]; + int num_channels_enabled = 0; + int ret; + + snprintf(socket_path, sizeof(socket_path), "%sfifo.%u", + CHANNEL_MGR_SOCKET_PATH, 0);...while here, it's an argument. What's the significance of 0 in this context? Also, maybe better to put it in a function, so as to only have one place to fix if anything changes, instead of two?
I'll add a function to generate this string. And I've dropped the ".0". It was inherited from the VM channel code, and in this case there is no index needed.
Quoted 6 lines
Quoted 3 lines
+
+ errno = 0;
+ ret =mkfifo(socket_path, 0666);0666 seems like overly permissive to me?
changed to 660
Quoted 5 lines
Quoted 2 lines
+ if ((errno != EEXIST) && (ret < 0)) {
+printf(" %d %d, %d\n", ret, EEXIST, errno);This looks like a leftover debug printf?
Removed in next rev.
Quoted 10 lines
Also, maybe if (ret < 0 && errno != EEXIST)? I don't think there's a need to set errno beforehand here.
Quoted 6 lines
+ RTE_LOG(ERR,
CHANNEL_MANAGER, "Cannot create fifo '%s' error: " + "%s\n",socket_path, strerror(errno));
+ return 0;
+ }
+
+ errno = 0;...and here too - if
access()call failed, does it not always set errno value?
Removed in next rev.
Quoted 11 lines
Quoted 8 lines
+ if (
access(socket_path, F_OK)< 0) {
+ RTE_LOG(ERR,CHANNEL_MANAGER, "Channel path '%s' error: " + "%s\n",socket_path, strerror(errno)); + return 0;
+ }
+chan_info= rte_malloc(NULL,sizeof(*chan_info),
+RTE_CACHE_LINE_SIZE);0 alignment is equivalent to
RTE_CACHE_LINE_SIZE, so no need to specify it explicitly.
Sure. Changed to 0.
Quoted 11 lines
Quoted 8 lines
+ if (
chan_info== NULL) {
+ RTE_LOG(ERR,CHANNEL_MANAGER, "Error allocating memory for " + "channel '%s'\n",socket_path);
+ return 0;
+ }
+ snprintf(chan_info->channel_path,
+sizeof(chan_info->channel_path), "%sfifo.%u", +CHANNEL_MGR_SOCKET_PATH, 0);Creating FIFO path again. Definitely needs a function :)
Function created. :)
Quoted 15 lines
Quoted 15 lines
+ if (
setup_host_channel_info(&chan_info, 0)< 0) { +rte_free(chan_info);
+ return 0;
+ }
+ num_channels_enabled++;examples/vm_power_manager/channel_manager.c +4
-0+ + return num_channels_enabled; +} +int
remove_channel(struct channel_info **chan_info_dptr){examples/vm_power_manager/channel_manager.h +0
-1--- a/examples/vm_power_manager/channel_manager.h
Quoted 9 lines
Quoted 6 lines
+++
b/examples/vm_power_manager/channel_manager.hexamples/vm_power_manager/channel_manager.h +0
-0@@ -37,7 +37,7 @@ struct sockaddr_un _sockaddr_un; #define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path) #endif-#define
MAX_VMS4
+#defineMAX_VMS64This change probably needs to be called out in commit message and explained. Or broken into a separate commit? Also, i think technically "
MAX_VMS" is a bad name now that you're supporting containers as well as VM's.MAX_CLIENTSmaybe?
Sure. I've split it out into it's own commit in next version, and renamed it as MAX_CLIENTS.
Quoted 9 lines
Quoted 6 lines
#define
MAX_VCPUS20
@@ -54,6 +54,11 @@ enumchannel_status{CHANNEL_MGR_CHANNEL_DISCONNECTED= 0,CHANNEL_MGR_CHANNEL_DISABLED,
CHANNEL_MGR_CHANNEL_PROCESSING};
+/* Communication Channel Type */
+enumchannel_type{CHANNEL_TYPE_BINARY= 0,Should probably start values on a new line?
I was sticking with the existing style, but I do prefer the new lines. Will change in the new version.
Quoted 21 lines
Quoted 7 lines
+
CHANNEL_TYPE_INI,
+CHANNEL_TYPE_JSON};
+
/* VM libvirt(qemu/KVM) connection status */
enumvm_status{CHANNEL_MGR_VM_INACTIVE= 0,CHANNEL_MGR_VM_ACTIVE}; @@ -66,6 +71,7 @@ structchannel_info{
volatileuint32_tstatus; /**< Connectionstatus(enum channel_status)*/<snip>
Quoted 11 lines
- pol->core_share[count].pcpu = pcpu;
-printf("Monitoring pcpu %d\n", pcpu); - }
+ RTE_LOG(INFO,CHANNEL_MONITOR,
+ "Looking for pcpu for %s\n",pol->pkt.vm_name); +
+ /*
+ * So now that we're handling virtual and physical cores, we need to
+ * differenciate between them when adding them to the branch monitor.
Quoted 9 lines
examples/vm_power_manager/channel_manager.h
Quoted 6 lines
+ * Virtual cores need to be converted to physical cores. + */
examples/vm_power_manager/channel_manager.h +4
-0+ + + +Needs moar newlines :)
One can never have enough newlines. :)
Removed in the next version.
Quoted 21 lines
Quoted 7 lines
+ if (
pol->pkt.core_type==CORE_TYPE_VIRTUAL) {
+ /*
+ * If the cores in the policy are virtual, we need to map them + * to physical core. We look up the vm info and use that for + * the mapping.
+ */
+get_info_vm(pol->pkt.vm_name, &info);<snip>
Quoted 11 lines
examples/vm_power_manager/channel_manager.h +0
-1@@ -362,10 +425,12 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info) if (pkt->command == CPU_POWER) { core_mask = get_pcpus_mask(chan_info, pkt->resource_id); if (core_mask == 0) { - RTE_LOG(ERR, CHANNEL_MONITOR, "Error get physical CPUmask for "
- "channel '%s' using vCPU(%u)\n",chan_info->channel_path,
- (unsigned)pkt->unit);
- return -1;
Quoted 10 lines
Quoted 6 lines
+ /*
+ * Core mask will be 0 in the case where + * hypervisor is not available so we're working in + * the host, so use the core as the mask. + */
+core_mask= 1 <<pkt->resource_id;1ULL?
Done in next version .
Thanks for the review, Anatoly.
Rgds,
Dave.
PATCH v3 5/8 examples/power: add json string handling
In reply to David HuntAdd JSON string handling to vm_power_manager for JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, the vm_power_manager user guide documentation updates.
This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
--- examples/vm_power_manager/Makefile | 6 + examples/vm_power_manager/channel_monitor.c | 297 +++++++++++++++++--- 2 files changed, 258 insertions(+), 45 deletions(-)
examples/vm_power_manager/Makefile +6 -0
@@ -31,6 +31,12 @@ CFLAGS += $(WERROR_FLAGS) LDLIBS += -lvirt +JANSSON := $(shell pkg-config --exists jansson; echo $$?) +ifeq ($(JANSSON), 0) +LDLIBS += $(shell pkg-config --libs jansson) +CFLAGS += -DUSE_JANSSON +endif + ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
examples/vm_power_manager/channel_monitor.c +252 -45
383 lines not on this page · raw message
Signature · 1 line
2.17.1
Re: [PATCH v3 5/8] examples/power: add json string handling
Quoted 11 lines · David Hunt
Add JSON string handling to
vm_power_managerfor JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, thevm_power_manageruser guide documentation updates.This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
Signed-off-by David Hunt <[email protected]>---
<snip>
Quoted 9 lines
void channel_monitor_exit(void) { run_loop = 0;examples/vm_power_manager/channel_monitor.c +0
-2@@ -124,18 +259,11 @@ get_pcpu_to_control(struct policy *pol) ci =get_core_info (); -RTE_LOG (INFO ,CHANNEL_MONITOR , -"Looking for pcpu for %s\n" , pol->pkt.vm_name);
examples/vm_power_manager/channel_monitor.c get_pcpu_to_control(struct policy *pol) · line 138
Quoted 10 lines
examples/vm_power_manager/channel_monitor.c +0
-5-/* * So now that we're handling virtual and physical cores, we need to * differenciate between them when adding them to the branch monitor. * Virtual cores need to be converted to physical cores. */ - - - -
Now you're removing those newlines you added in previous commit :)
examples/vm_power_manager/channel_monitor.c apply_traffic_profile(struct policy *pol) · line 299
Quoted 9 lines
examples/vm_power_manager/channel_monitor.c +0
-2if (pol->pkt.core_type ==CORE_TYPE_VIRTUAL ) {/* * If the cores in the policy are virtual, we need to map them @@ -295,8 +423,6 @@ apply_traffic_profile(struct policy *pol) diff =get_pkt_diff (pol); -RTE_LOG (INFO ,CHANNEL_MONITOR ,"Applying traffic profile\n" ); -
Here and in a few other places: these log message removals look to be unrelated to this commit. Also, in my experience, more logging is better than less logging, especially when something goes wrong - maybe instead of removing them, just switch the level to debug?
Quoted 8 lines
examples/vm_power_manager/channel_monitor.c +0
-1if (diff >= (pol->pkt.traffic_policy.max_max_packet_thresh)) {for (count =0 ; count < pol->pkt.num_vcpu; count++) {if (pol->core_share[count].status !=1 )@@ -340,9 +466,6 @@ apply_time_profile(struct policy *pol)if (pol->core_share[count].status !=1 ) {power_manager_scale_core_max ( pol->core_share[count].pcpu); - RTE_LOG(INFO, CHANNEL_MONITOR,
<snip>
examples/vm_power_manager/channel_monitor.c channel_monitor_init(void) · line 730
Quoted 10 lines
examples/vm_power_manager/channel_monitor.c +10
-0+int idx =0 ; +int indent =0 ; + do { + n_bytes = read(chan_info->fd, &json_data[idx], 1); + if (n_bytes == 0) + break; + if (json_data[idx] == '{') + indent++; + if (json_data[idx] == '}') + indent--;
What happens if someone sends a string with a "{" or "}" inside?
examples/vm_power_manager/channel_monitor.c channel_monitor_init(void) · line 731
Quoted 1 line
examples/vm_power_manager/channel_monitor.c +1
-0+if ((indent >0 ) || (idx >>0 ))
idx > 0?
examples/vm_power_manager/channel_monitor.c channel_monitor_init(void) · line 736
Quoted 5 lines
examples/vm_power_manager/channel_monitor.c +5
-0+ idx++; +if (indent ==0 ) + json_data[idx] =0 ; +if (idx >=MAX_JSON_STRING_LEN ) +break ;
This looks like a potential overflow to me, because you increment idx, check if it's >= max, but still write into that location if indent == 0 on previous line.
examples/vm_power_manager/channel_monitor.c channel_monitor_init(void) · line 742
Quoted 6 lines
examples/vm_power_manager/channel_monitor.c +6
-0+ }while (indent >0 ); + +if (indent >0 ) +/* +* We've broken out of the read loop without getting +* a closing brace, so throw away the datai
I think "data" is plural already, no need to invent a new word :)
examples/vm_power_manager/channel_monitor.c channel_monitor_init(void) · line 744
Quoted 2 lines
examples/vm_power_manager/channel_monitor.c +2
-0+*/ + json_data[idx] =0 ;
idx could potentially be overflown already due to code above?
Quoted 6 lines
examples/vm_power_manager/channel_monitor.c +6
-0+ +if (strlen (json_data) ==0 ) +continue ; + +printf ("got [%s]\n" , json_data); +
<snip>
examples/vm_power_manager/channel_monitor.c run_channel_monitor(void) · line 791
Quoted 11 lines
void run_channel_monitor(void) {examples/vm_power_manager/channel_monitor.c +4
-0@@ -570,11 +785,16 @@ run_channel_monitor(void)if (!run_loop)break ;for (i =0 ; i < n_events; i++) { +if (!global_events_list[i].data.ptr) { +fflush (stdout); +continue ; + }
This change looks unrelated to this commit.
Quoted 3 lines
examples/vm_power_manager/channel_monitor.c +0
-0struct channel_info *chan_info = (struct channel_info *) global_events_list[i].data.ptr; if ((global_events_list[i].events & EPOLLERR) ||
Signature · 2 lines
Thanks, Anatoly
Re: [PATCH v3 5/8] examples/power: add json string handling
Hi Anatoly,
Quoted 26 lines · Anatoly
Quoted 11 lines · David Hunt
Add JSON string handling to
vm_power_managerfor JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, thevm_power_manageruser guide documentation updates.This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
Signed-off-by David Hunt <[email protected]>---
<snip>
Quoted 11 lines
void
channel_monitor_exit(void)
{
run_loop= 0;examples/vm_power_manager/channel_monitor.c +0
-2@@ -124,18 +259,11 @@ get_pcpu_to_control(struct policy *pol) ci = get_core_info(); - RTE_LOG(INFO, CHANNEL_MONITOR, - "Looking for pcpu for %s\n", pol->pkt.vm_name); - /** So now that we're handling virtual and physical cores, we need to * differenciate between them when adding them to the branch monitor.
Quoted 9 lines
examples/vm_power_manager/channel_monitor.c get_pcpu_to_control(struct policy *pol) · line 138
Quoted 6 lines
examples/vm_power_manager/channel_monitor.c +0
-4* Virtual cores need to be converted to physical cores. */ - - - -Now you're removing those newlines you added in previous commit :)
Fixed in previous patch in the next version.
Quoted 10 lines
examples/vm_power_manager/channel_monitor.c apply_traffic_profile(struct policy *pol) · line 297
Quoted 7 lines
examples/vm_power_manager/channel_monitor.c +0
-1if (pol->pkt.core_type == CORE_TYPE_VIRTUAL) { /** If the cores in the policy are virtual, we need to map them @@ -295,8 +423,6 @@ apply_traffic_profile(struct policy *pol) diff = get_pkt_diff(pol); - RTE_LOG(INFO, CHANNEL_MONITOR, "Applying traffic profile\n"); -Here and in a few other places: these log message removals look to be unrelated to this commit. Also, in my experience, more logging is better than less logging, especially when something goes wrong - maybe instead of removing them, just switch the level to debug?
Changed to Debug instead. Was causing quite a verbose output.
Quoted 22 lines
Quoted 8 lines
examples/vm_power_manager/channel_monitor.c +0
-0if (diff >= (pol->pkt.traffic_policy.max_max_packet_thresh)) { for (count = 0; count < pol->pkt.num_vcpu; count++) { if (pol->core_share[count].status != 1)@@ -340,9 +466,6 @@ apply_time_profile(struct policy *pol) if (pol->core_share[count].status != 1) {
power_manager_scale_core_max( pol->core_share[count].pcpu); - RTE_LOG(INFO,CHANNEL_MONITOR,<snip>
Quoted 10 lines
+ int idx = 0;
+ int indent = 0;
+ do {
+n_bytes=read(chan_info->fd, &json_data[idx], 1); + if (n_bytes== 0)
+ break;
+ if (json_data[idx] == '{')
+ indent++;
+ if (json_data[idx] == '}')
+ indent--;
Quoted 2 lines
What happens if someone sends a string with a "{" or "}" inside?
If we get to the end of the buffer without a "}", it calls the library to convert, will fail, and move on. No damage done (I hope). Also, a short un-terminated (by "}") string will also exit when no characters read.
So any invalid JSON string that's send to Jansson will fail to parse, and the application will be ready for the next (hopefully valid) JSON string.
Quoted 4 lines
Quoted 1 line
+ if ((indent > 0) || (idx >> 0))
idx > 0?
Yes, will fix.
Quoted 8 lines
Quoted 5 lines
+ idx++;
+ if (indent == 0)
+ json_data[idx] = 0;
+ if (idx >=MAX_JSON_STRING_LEN)
+ break;This looks like a potential overflow to me, because you increment idx, check if it's >= max, but still write into that location if indent == 0 on previous line.
Yes, will exit at MAX_JSON_STRING_LEN-1
Quoted 7 lines
Quoted 6 lines
+ } while (indent > 0);
+
+ if (indent > 0)
+ /*
+ * We've broken out of the read loop without getting + * a closing brace, so throw away the datai
Quoted 7 lines
I think "data" is plural already, no need to invent a new word :)
Quoted 2 lines
+ */
+ json_data[idx] = 0;idx could potentially be overflown already due to code above?
Typo fixed in next version.
Quoted 9 lines
Quoted 6 lines
examples/vm_power_manager/channel_monitor.c +6
-0+ + if (strlen(json_data) == 0) + continue; + + printf("got [%s]\n", json_data); +<snip>
Quoted 13 lines
examples/vm_power_manager/channel_monitor.c run_channel_monitor(void) · line 791
Quoted 11 lines
void
run_channel_monitor(void)
{examples/vm_power_manager/channel_monitor.c +4
-0@@ -570,11 +785,16 @@ run_channel_monitor(void) if (!run_loop) break; for (i = 0; i < n_events; i++) { + if (!global_events_list[i].data.ptr) { + fflush(stdout); + continue; + }This change looks unrelated to this commit.
There was a few printfs in there, this change will be removed altogether in next version.
Quoted 5 lines
Quoted 4 lines
examples/vm_power_manager/channel_monitor.c +0
-0struct channel_info *chan_info = (struct channel_info *) global_events_list[i].data.ptr;if ((global_events_list[i].events & EPOLLERR) ||
Thanks,
Dave.
Re: [PATCH v3 5/8] examples/power: add json string handling
Quoted 17 lines · David
Quoted 2 lines
Now you're removing those newlines you added in previous commit :)
Fixed in previous patch in the next version.
Quoted 10 lines
examples/vm_power_manager/channel_monitor.c apply_traffic_profile(struct policy *pol) · line 297
Quoted 7 lines
if (
pol->pkt.core_type==CORE_TYPE_VIRTUAL) {
/*
* If the cores in the policy are virtual, we need to map themexamples/vm_power_manager/channel_monitor.c +0
-1@@ -295,8 +423,6 @@ apply_traffic_profile(struct policy *pol) diff = get_pkt_diff(pol); - RTE_LOG(INFO, CHANNEL_MONITOR, "Applying traffic profile\n"); -Here and in a few other places: these log message removals look to be unrelated to this commit. Also, in my experience, more logging is better than less logging, especially when something goes wrong - maybe instead of removing them, just switch the level to debug?
Quoted 1 line
Changed to Debug instead. Was causing quite a verbose output.
Hopefully in a separate commit :)
Quoted 23 lines
Quoted 23 lines
Quoted 9 lines
examples/vm_power_manager/channel_monitor.c +0
-0if (diff >= (pol->pkt.traffic_policy.max_max_packet_thresh)) { for (count = 0; count < pol->pkt.num_vcpu; count++) { if (pol->core_share[count].status != 1)@@ -340,9 +466,6 @@ apply_time_profile(struct policy *pol) if (pol->core_share[count].status != 1) {
power_manager_scale_core_max( pol->core_share[count].pcpu); - RTE_LOG(INFO,CHANNEL_MONITOR,<snip>
Quoted 10 lines
+ int idx = 0;
+ int indent = 0;
+ do {
+n_bytes=read(chan_info->fd, &json_data[idx], 1); + if (n_bytes== 0)
+ break;
+ if (json_data[idx] == '{')
+ indent++;
+ if (json_data[idx] == '}')
+ indent--;
Quoted 6 lines
Quoted 2 lines
What happens if someone sends a string with a "{" or "}" inside?
If we get to the end of the buffer without a "}", it calls the library to convert, will fail, and move on. No damage done (I hope). Also, a short un-terminated (by "}") string will also exit when no characters read.
So any invalid JSON string that's send to Jansson will fail to parse, and the application will be ready for the next (hopefully valid) JSON string.
No, what i meant is something like this:
{ "json_value": "{"}
According to JSON validator, this is a valid JSON string, but it will break your code :)
Signature · 2 lines
Thanks, Anatoly
Re: [PATCH v3 5/8] examples/power: add json string handling
Quoted 18 lines · Anatoly
Quoted 17 lines · David
Quoted 2 lines
Now you're removing those newlines you added in previous commit :)
Fixed in previous patch in the next version.
Quoted 10 lines
examples/vm_power_manager/channel_monitor.c apply_traffic_profile(struct policy *pol) · line 297
Quoted 7 lines
if (
pol->pkt.core_type==CORE_TYPE_VIRTUAL) {
/*
* If the cores in the policy are virtual, we need to map themexamples/vm_power_manager/channel_monitor.c +0
-1@@ -295,8 +423,6 @@ apply_traffic_profile(struct policy *pol) diff = get_pkt_diff(pol); - RTE_LOG(INFO, CHANNEL_MONITOR, "Applying traffic profile\n"); -Here and in a few other places: these log message removals look to be unrelated to this commit. Also, in my experience, more logging is better than less logging, especially when something goes wrong - maybe instead of removing them, just switch the level to debug?
Quoted 4 lines
Quoted 1 line
Changed to Debug instead. Was causing quite a verbose output.
Hopefully in a separate commit :)
Of Course. :)
Quoted 30 lines
Quoted 23 lines
Quoted 23 lines
Quoted 9 lines
examples/vm_power_manager/channel_monitor.c +0
-0if (diff >= (pol->pkt.traffic_policy.max_max_packet_thresh)) { for (count = 0; count < pol->pkt.num_vcpu; count++) { if (pol->core_share[count].status != 1)@@ -340,9 +466,6 @@ apply_time_profile(struct policy *pol) if (pol->core_share[count].status != 1) {
power_manager_scale_core_max( pol->core_share[count].pcpu); - RTE_LOG(INFO,CHANNEL_MONITOR,<snip>
Quoted 10 lines
+ int idx = 0;
+ int indent = 0;
+ do {
+n_bytes=read(chan_info->fd, &json_data[idx], 1); + if (n_bytes== 0)
+ break;
+ if (json_data[idx] == '{')
+ indent++;
+ if (json_data[idx] == '}')
+ indent--;Quoted 6 lines
Quoted 2 lines
What happens if someone sends a string with a "{" or "}" inside?
If we get to the end of the buffer without a "}", it calls the library to convert, will fail, and move on. No damage done (I hope). Also, a short un-terminated (by "}") string will also exit when no characters read.
So any invalid JSON string that's send to Jansson will fail to parse, and the application will be ready for the next (hopefully valid) JSON string.
Quoted 6 lines
No, what i meant is something like this:
{ "
json_value": "{"}According to JSON validator, this is a valid JSON string, but it will break your code :)
You are correct if this code was designed to be a general purpose JSON string reader. However, it's only designed to take in strings for this sample application, and they do not expect any brace characters embedded within quotes. So I think it's OK for this use case. Patches welcome, though! :)
Thanks,
Dave.
Re: [PATCH v3 5/8] examples/power: add json string handling
Quoted 7 lines · David
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
What happens if someone sends a string with a "{" or "}" inside?
If we get to the end of the buffer without a "}", it calls the library to convert, will fail, and move on. No damage done (I hope). Also, a short un-terminated (by "}") string will also exit when no characters read.
So any invalid JSON string that's send to Jansson will fail to parse, and the application will be ready for the next (hopefully valid) JSON string.
Quoted 9 lines
Quoted 6 lines
No, what i meant is something like this:
{ "
json_value": "{"}According to JSON validator, this is a valid JSON string, but it will break your code :)
You are correct if this code was designed to be a general purpose JSON string reader. However, it's only designed to take in strings for this sample application, and they do not expect any brace characters embedded within quotes. So I think it's OK for this use case. Patches welcome, though! :)
Fair enough :)
Quoted 5 lines
Thanks,
Dave.
Signature · 2 lines
Thanks, Anatoly
PATCH v3 6/8 examples/power: add meson/ninja build support
In reply to David HuntAdd meson.build in vm_power_manager and the guest_cli subdirectory. Building can be achieved by going to the build directory, and using
meson configure -Dexamples=vm_power_manager,vm_power_manager/guest_cli
Then, when ninja is invoked, it will build dpdk-vm_power_manger and dpdk-guest_cli
Work still needs to be done on the meson build system to handles the case where the target list of example apps is defined as 'all'. That will come in a future patch.
--- .../vm_power_manager/guest_cli/meson.build | 21 +++++++++++ examples/vm_power_manager/meson.build | 37 ++++++++++++++++++- 2 files changed, 56 insertions(+), 2 deletions(-) create mode 100644 examples/vm_power_manager/guest_cli/meson.build
examples/vm_power_manager/guest_cli/meson.build new file +21 -0
@@ -0,0 +1,21 @@ +# SPDX-License-Identifier: BSD-3-Clause +# Copyright(c) 2018 Intel Corporation + +# meson file, for building this example as part of a main DPDK build. +# +# To build this example as a standalone application with an already-installed +# DPDK instance, use 'make' + +# Setting the name here because the default name will conflict with the +# vm_power_manager app because of the way the directories are parsed. +name = 'guest_cli' + +deps += ['power'] + +sources = files( + 'main.c', 'parse.c', 'vm_power_cli_guest.c' +) + +opt_dep = cc.find_library('virt', required : false) +build = opt_dep.found() +ext_deps += opt_dep
examples/vm_power_manager/meson.build +35 -2
@@ -6,5 +6,38 @@ # To build this example as a standalone application with an already-installed # DPDK instance, use 'make' -# Example app currently unsupported by meson build -build = false +if dpdk_conf.has('RTE_LIBRTE_BNXT_PMD') + deps += ['pmd_bnxt'] +endif + +if dpdk_conf.has('RTE_LIBRTE_I40E_PMD') + deps += ['pmd_i40e'] +endif + +if dpdk_conf.has('RTE_LIBRTE_IXGBE_PMD') + deps += ['pmd_ixgbe'] +endif + +deps += ['power'] + + +sources = files( + 'channel_manager.c', 'channel_monitor.c', 'main.c', 'parse.c', 'power_manager.c', 'vm_power_cli.c' +) + +# If we're on X86, pull in the x86 code for the branch monitor algo. +if dpdk_conf.has('RTE_ARCH_X86_64') + sources += files('oob_monitor_x86.c') +else + sources += files('oob_monitor_nop.c') +endif + +opt_dep = cc.find_library('virt', required : false) +build = opt_dep.found() +ext_deps += opt_dep + +opt_dep = dependency('jansson', required : false) +if opt_dep.found() + ext_deps += opt_dep + cflags += '-DUSE_JANSSON' +endif
Signature · 1 line
2.17.1
Re: [PATCH v3 6/8] examples/power: add meson/ninja build support
Quoted 8 lines · David Hunt
Add meson.build in
vm_power_managerand theguest_clisubdirectory. Building can be achieved by going to the build directory, and usingmeson configure -Dexamples=vm_power_manager,vm_power_manager/guest_cli
Then, when ninja is invoked, it will build dpdk-vm_power_manger and dpdk-guest_cli
Quoted 6 lines
Work still needs to be done on the meson build system to handles the case where the target list of example apps is defined as 'all'. That will come in a future patch.
Signed-off-by David Hunt <[email protected]>---
The examples=all limitation only applies to the guest_cli app, because it's in a subdirectory. That should be possible to manage in a later changeset, but this is good for now, as it still has the main app buildable with the test-meson-builds script.
PATCH v3 7/8 doc/vm_power_manager: add JSON interface API info
In reply to David HuntAlso added meson/ninja build info
--- .../sample_app_ug/vm_power_management.rst | 272 +++++++++++++++++- 1 file changed, 270 insertions(+), 2 deletions(-)
doc/guides/sample_app_ug/vm_power_management.rst +270 -2
@@ -199,7 +199,7 @@ see :doc:`compiling`. The application is located in the ``vm_power_manager`` sub-directory. -To build just the ``vm_power_manager`` application: +To build just the ``vm_power_manager`` application using ``make``: .. code-block:: console
@@ -208,6 +208,22 @@ To build just the ``vm_power_manager`` application: cd ${RTE_SDK}/examples/vm_power_manager/ make +The resulting binary will be ${RTE_SDK}/build/examples/vm_power_manager + +To build just the ``vm_power_manager`` application using ``meson/ninja``: + +.. code-block:: console + + export RTE_SDK=/path/to/rte_sdk + cd ${RTE_SDK} + meson build + cd build + ninja + meson configure -Dexamples=vm_power_manager + ninja + +The resulting binary will be ${RTE_SDK}/build/examples/dpdk-vm_power_manager + Running ~~~~~~~
@@ -337,6 +353,242 @@ monitoring of branch ratio on cores doing busy polling via PMDs. and will need to be adjusted for different workloads. + +JSON API +~~~~~~~~ + +In addition to the command line interface for host command and a virtio-serial +interface for VM power policies, there is also a JSON interface through which +power commands and policies can be sent. This functionality adds a dependency +on the Jansson library, and the Jansson development package must be installed +on the system before the JSON parsing functionality is included in the app. +This is achieved by: + + .. code-block:: console + + apt-get install libjansson-dev + +The command and package name may be different depending on your operating +system. It's worth noting that the app will successfully build without this +package present, but a warning is shown during compilation, and the JSON +parsing functionality will not be present in the app. + +Sending a command or policy to the power manager application is achieved by +simply opening a fifo file, writing a JSON string to that fifo, and closing +the file. + +The fifo is at /tmp/powermonitor/fifo.0 + +The jason string can be a policy or instruction, and takes the following +format: + + .. code-block:: console + + {"packet_type": { + "pair_1": value, + "pair_2": value + }} + +The 'packet_type' header can contain one of two values, depending on +whether a policy or power command is being sent. The two possible values are +"policy" and "instruction", and the expected name-value pairs is different +depending on which type is being sent. + +The pairs are the format of standard JSON name-value pairs. The value type +varies between the different name/value pairs, and may be intgers, strings, +arrays, etc. Examples of policies follow later in this document. The allowed +names and value types are as follows: + + +:Pair Name: "name" +:Description: Name of the VM or Host. Allows the parser to associate the + policy with the relevant VM or Host OS. +:Type: string +:Values: any valid string +:Required: yes +:Example: + + .. code-block:: console + + ""name", "ubuntu2" + + +:Pair Name: "command" +:Description: The type of packet we're sending to the power manager. We can be + creating or destroying a policy, or sending a direct command to adjust + the frequency of a core, similar to the command line interface. +:Type: string +:Values: + + :"CREATE": used when creating a new policy, + :"DESTROY": used when removing a policy, + :"POWER": used when sending an immediate command, max, min, etc. +:Required: yes +:Example: + + .. code-block:: console + + "command", "CREATE" + + +:Pair Name: "policy_type" +:Description: Type of policy to apply. Please see vm_power_manager documentation + for more information on the types of policies that may be used. +:Type: string +:Values: + + :"TIME": Time-of-day policy. Frequencies of the relevant cores are + scaled up/down depending on busy and quiet hours. + :"TRAFFIC": This policy takes statistics from the NIC and scales up + and down accordingly. + :"WORKLOAD": This policy looks at how heavily loaded the cores are, + and scales up and down accordingly. + :"BRANCH_RATIO": This out-of-band policy can look at the ratio between + branch hits and misses on a core, and is useful for detecting + how much packet processing a core is doing. +:Required: only for CREATE/DESTROY command +:Example: + + .. code-block:: console + + "policy_type", "TIME" + +:Pair Name: "busy_hours" +:Description: The hours of the day in which we scale up the cores for busy + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console + + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ] + +:Pair Name: "quiet_hours" +:Description: The hours of the day in which we scale down the cores for quiet + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console + + "quiet_hours":[ 2, 3, 4, 5, 6 ] + +:Pair Name: "avg_packet_thresh" +:Description: Threshold below which the frequency will be set to min for + the TRAFFIC policy. If the traffic rate is above this and below max, the + frequency will be set to medium. +:Type: integer +:Values: The number of packets below which the TRAFFIC policy applies the + minimum frequency, or medium frequency if between avg and max thresholds. +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: console + + "avg_packet_thresh": 100000 + +:Pair Name: "max_packet_thresh" +:Description: Threshold above which the frequency will be set to max for + the TRAFFIC policy +:Type: integer +:Values: The number of packets per interval above which the TRAFFIC policy + applies the maximum frequency +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: console + + "max_packet_thresh": 500000 + +:Pair Name: "core_list" +:Description: The cores to which to apply the policy. +:Type: array of integers +:Values: array with list of virtual CPUs. +:Required: only policy CREATE/DESTROY +:Example: + + .. code-block:: console + + "core_list":[ 10, 11 ] + +:Pair Name: "unit" +:Description: the type of power operation to apply in the command +:Type: string +:Values: + + :"SCALE_MAX": Scale frequency of this core to maximum + :"SCALE_MIN": Scale frequency of this core to minimum + :"SCALE_UP": Scale up frequency of this core + :"SCALE_DOWN": Scale down frequency of this core + :"ENABLE_TURBO": Enable Turbo Boost for this core + :"DISABLE_TURBO": Disable Turbo Boost for this core +:Required: only for POWER instruction +:Example: + + .. code-block:: console + + "unit", "SCALE_MAX" + +:Pair Name: "resource_id" +:Description: The core to which to apply the power command. +:Type: integer +:Values: valid core id for VM or host OS. +:Required: only POWER instruction +:Example: + + .. code-block:: console + + "resource_id": 10 + +JSON API Examples +~~~~~~~~~~~~~~~~~ + +Profile create example: + + .. code-block:: console + + {"policy": { + "name": "ubuntu", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11 ] + }} + +Profile destroy example: + + .. code-block:: console + + {"profile": { + "name": "ubuntu", + "command": "destroy", + }} + +Power command example: + + .. code-block:: console + + {"command": { + "name": "ubuntu", + "unit": "SCALE_MAX", + "resource_id": 10 + }} + +To send a JSON string to the Power Manager application, simply paste the +example JSON string into a text file and cat it into the fifo: + + .. code-block:: console + + cat file.json >/tmp/powermonitor/fifo.0 + +The console of the Power Manager application should indicate the command that +was just received via the fifo. + Compiling and Running the Guest Applications --------------------------------------------
@@ -366,7 +618,7 @@ For compiling and running l3fwd-power, see :doc:`l3_forward_power_man`. The application is located in the ``guest_cli`` sub-directory under ``vm_power_manager``. -To build just the ``guest_vm_power_manager`` application: +To build just the ``guest_vm_power_manager`` application using ``make``: .. code-block:: console
@@ -375,6 +627,22 @@ To build just the ``guest_vm_power_manager`` application: cd ${RTE_SDK}/examples/vm_power_manager/guest_cli/ make +The resulting binary will be ${RTE_SDK}/build/examples/guest_cli + +To build just the ``vm_power_manager`` application using ``meson/ninja``: + +.. code-block:: console + + export RTE_SDK=/path/to/rte_sdk + cd ${RTE_SDK} + meson build + cd build + ninja + meson configure -Dexamples=vm_power_manager/guest_cli + ninja + +The resulting binary will be ${RTE_SDK}/build/examples/guest_cli + Running ~~~~~~~
Signature · 1 line
2.17.1
PATCH v3 8/8 examples/power: add json example files
In reply to David HuntThis patch provides some example files in the json_examples sub-directory for sending to the fifo.
--- examples/vm_power_manager/json_examples/README | 6 ++++++ examples/vm_power_manager/json_examples/create.json | 8 ++++++++ examples/vm_power_manager/json_examples/destroy.json | 4 ++++ examples/vm_power_manager/json_examples/set_core_max.json | 6 ++++++ examples/vm_power_manager/json_examples/set_core_min.json | 6 ++++++ 5 files changed, 30 insertions(+) create mode 100644 examples/vm_power_manager/json_examples/README create mode 100644 examples/vm_power_manager/json_examples/create.json create mode 100644 examples/vm_power_manager/json_examples/destroy.json create mode 100644 examples/vm_power_manager/json_examples/set_core_max.json create mode 100644 examples/vm_power_manager/json_examples/set_core_min.json
examples/vm_power_manager/json_examples/README new file +6 -0
@@ -0,0 +1,6 @@ +Sample files for sending to the vm_power_manager through the fifo. + +Simply cat the file to /tmp/powermonitor/fifo.0 when the vm_power_manager +application is running. + +E.g. cat create.json >/tmp/powermonitor/fifo.0
examples/vm_power_manager/json_examples/create.json new file +8 -0
@@ -0,0 +1,8 @@ +{"policy": { + "name": "policy-1", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11, 12 ] +}}
examples/vm_power_manager/json_examples/destroy.json new file +4 -0
@@ -0,0 +1,4 @@ +{"policy": { + "name": "policy-1", + "command": "destroy" +}}
examples/vm_power_manager/json_examples/set_core_max.json new file +6 -0
@@ -0,0 +1,6 @@ +{"instruction": { + "name": "set_power", + "command": "power", + "unit": "SCALE_MAX", + "resource_id": 10 +}}
examples/vm_power_manager/json_examples/set_core_min.json new file +6 -0
@@ -0,0 +1,6 @@ +{"instruction": { + "name": "set_power", + "command": "power", + "unit": "SCALE_MIN", + "resource_id": 10 +}}
Signature · 1 line
2.17.1
v4 cover add json power policy interface for containers
In reply to David HuntThe current vm_power_manager example app has the capability to accept power policies from virtual machines via virtio-serial channels. These power policies allow a virtual machine to give information to the power manager to allow the power manager take care of the power management of the virtual machine based on the information in the policy.
This power policy functionality is limited to virtual machines sending the policies to the power manager (which runs in the Host OS), and a solution was needed for additional methods of sending power policies to the power manager app.
The main use-case for this modification is for containers and host applications that wish to send polices to the power manager.
This patchset adds the capability to send power polices and power commands to the vm_power_manager app via JSON strings through a fifo on the file system.
For example, given the following file, policy.json:
{"policy": {
"name": "ubuntu2",
"command": "create",
"policy_type": "TIME",
"busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ],
"quiet_hours":[ 2, 3, 4, 5, 6 ],
"core_list":[ 11, 12, 13 ]
}}
Then running the command:
cat policy.json >/tmp/powermonitor/fifo
The policy is sent to the vm_power_manager. The power manager app then parses the JSON data, and inserts the policy into the array of policies.
Part of the patch series contains documentation updates to give all the details of the valid name-value pairs, the data types, etc.
Patch v2:
* Fixed review comments from Stephen Hemminger and Lei A Yao.
* Added a check in the Makefile for libjansson-dev. Will Warn user and build without JSON functionality if not present, will build including JSON functionality if it is present.
Patch v3:
* Added meson/ninja support for vm_power_manager and guest_cli apps
* Fixed compilation issue with guest_cli app
Patch v4:
* Split out some unrelated changes to separate patches in the set
* Some changes out of review by Anatoly (Thanks!)
[01/11] examples/power: add checks around hypervisor [02/11] examples/power: allow for number of vms to be zero [03/11] lib/power: add changes for host commands/policies [04/11] examples/power: add necessary changes to guest app [05/11] examples/power: add host channel to power manager [06/11] examples/power: increase allowed number of clients [07/11] examples/power: add json string handling [08/11] examples/power: clean up verbose messages [09/11] examples/power: add meson/ninja build support [10/11] doc/vm_power_manager: add JSON interface API info [11/11] examples/power: add json example files
PATCH v4 1/11 examples/power: add checks around hypervisor
Allow vm_power_manager to run without requiring qemu to be present on the machine. This will be required for instances where the JSON interface is used for commands and polices, without any VMs present. A use case for this is a container enviromnent.
--- examples/vm_power_manager/channel_manager.c | 71 +++++++++++++-------- 1 file changed, 43 insertions(+), 28 deletions(-)
examples/vm_power_manager/channel_manager.c +43 -28
@@ -43,7 +43,8 @@ static unsigned char *global_cpumaps;static virVcpuInfo *global_vircpuinfo;static size_t global_maplen; -static unsigned global_n_host_cpus; +static unsigned int global_n_host_cpus; +static bool global_hypervisor_available;/* * Represents a single Virtual Machine
@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) {struct virtual_machine_info *vm_info = (struct virtual_machine_info *)chan_info->priv_info; -return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); + +if (global_hypervisor_available && (vm_info !=NULL )) +return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); +else +return 0 ; } static inline int
@@ -559,6 +564,8 @@ get_all_vm(int *num_vm, int *num_vcpu)VIR_CONNECT_LIST_DOMAINS_PERSISTENT ;unsigned int domain_flag =VIR_DOMAIN_VCPU_CONFIG ; +if (!global_hypervisor_available) +return ;memset (global_cpumaps,0 ,CHANNEL_CMDS_MAX_CPUS *global_maplen);if (virNodeGetInfo (global_vir_conn_ptr, &node_info)) {
@@ -768,38 +775,42 @@ connect_hypervisor(const char *path) }return 0 ; } -int -channel_manager_init (const char *path) +channel_manager_init(const char *path __rte_unused) {virNodeInfo info;LIST_INIT (&vm_list_head);if (connect_hypervisor (path) <0 ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); -return -1 ; - } - - global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + global_n_host_cpus =64 ; + global_hypervisor_available =0 ; +RTE_LOG (INFO ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); + }else { + global_hypervisor_available =1 ; + + global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + + global_vircpuinfo =rte_zmalloc (NULL , +sizeof (*global_vircpuinfo) * +CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); +if (global_vircpuinfo ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); + goto error; + } + global_cpumaps =rte_zmalloc (NULL , +CHANNEL_CMDS_MAX_CPUS * global_maplen, +RTE_CACHE_LINE_SIZE ); +if (global_cpumaps ==NULL ) + goto error; - global_vircpuinfo =rte_zmalloc (NULL ,sizeof (*global_vircpuinfo) * -CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); -if (global_vircpuinfo ==NULL ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); - goto error; - } - global_cpumaps =rte_zmalloc (NULL ,CHANNEL_CMDS_MAX_CPUS * global_maplen, -RTE_CACHE_LINE_SIZE ); -if (global_cpumaps ==NULL ) { - goto error; +if (virNodeGetInfo (global_vir_conn_ptr, &info)) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); + goto error; + } + global_n_host_cpus = (unsigned int )info.cpus; } -if (virNodeGetInfo (global_vir_conn_ptr, &info)) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); - goto error; - } - global_n_host_cpus = (unsigned )info.cpus;if (global_n_host_cpus >CHANNEL_CMDS_MAX_CPUS ) { RTE_LOG(WARNING, CHANNEL_MANAGER, "The number of host CPUs(%u) exceeds the "
@@ -811,7 +822,8 @@ channel_manager_init(const char *path)return 0 ; error: -disconnect_hypervisor (); +if (global_hypervisor_available) +disconnect_hypervisor ();return -1 ; }
@@ -838,7 +850,10 @@ channel_manager_exit(void)rte_free (vm_info); } -rte_free (global_cpumaps); -rte_free (global_vircpuinfo); -disconnect_hypervisor (); +if (global_hypervisor_available) { +/* Only needed if hypervisor available */ +rte_free (global_cpumaps); +rte_free (global_vircpuinfo); +disconnect_hypervisor (); + } }
Signature · 1 line
2.17.1
Re: [PATCH v4 01/11] examples/power: add checks around hypervisor
Quoted 7 lines · David Hunt
Allow
vm_power_managerto run without requiring qemu to be present on the machine. This will be required for instances where the JSON interface is used for commands and polices, without any VMs present. A use case for this is a container enviromnent.Signed-off-by David Hunt <[email protected]>---
Signature · 2 lines
Thanks, Anatoly
PATCH v4 2/11 examples/power: allow for number of vms to be zero
In reply to David HuntPreviously the vm_power_manager app required to have some vms defined, so the call to get_all_vm() always set the noVms variable. Now we're accepting policies from the host OS (without any VMs defined), so it is now valid to have zero VMs. This patch initialises the relevant variables to zero just in case the call to get_all_vms() does not find any, so could return with the variables uninitialised.
--- examples/vm_power_manager/channel_monitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
examples/vm_power_manager/channel_monitor.c +1 -1
@@ -66,7 +66,7 @@ static void core_share_status(int pNo) { -int noVms, noVcpus, z, x, t; +int noVms =0 , noVcpus =0 , z, x, t;get_all_vm (&noVms, &noVcpus);
Signature · 1 line
2.17.1
Re: [PATCH v4 02/11] examples/power: allow for number of vms to be zero
Quoted 9 lines · David Hunt
Previously the
vm_power_managerapp required to have some vms defined, so the call toget_all_vm()always set the noVms variable. Now we're accepting policies from the host OS (without any VMs defined), so it is now valid to have zero VMs. This patch initialises the relevant variables to zero just in case the call toget_all_vms()does not find any, so could return with the variables uninitialised.Signed-off-by David Hunt <[email protected]>---
Signature · 2 lines
Thanks, Anatoly
PATCH v4 3/11 lib/power: add changes for host commands/policies
In reply to David HuntThis patch does a couple of things:
* Adds a new message type for removing policies (PKT_POLICY_REMOVE) Used when we want to remove a previously created policy.
* Adds a core_type bool to the channel packet struct to specify whether the type of core we want to control is cirtual or physical.
--- lib/librte_power/channel_commands.h | 5 +++++ 1 file changed, 5 insertions(+)
lib/librte_power/channel_commands.h +5 -0
@@ -19,6 +19,7 @@ extern "C" {#define CPU_POWER 1#define CPU_POWER_CONNECT 2#define PKT_POLICY 3 +#define PKT_POLICY_REMOVE 4/* CPU Power Command Scaling */ #define CPU_POWER_SCALE_UP 1
@@ -58,6 +59,9 @@ struct traffic {uint32_t max_max_packet_thresh; }; +#define CORE_TYPE_VIRTUAL 0 +#define CORE_TYPE_PHYSICAL 1 +struct channel_packet {uint64_t resource_id;/**< core_num, device */ uint32_t unit;/**< scale down/up/min/max */
@@ -70,6 +74,7 @@ struct channel_packet {uint8_t vcpu_to_control[MAX_VCPU_PER_VM ];uint8_t num_vcpu;struct timer_profile timer_policy; +bool core_type;enum workload workload;enum policy_to_use policy_to_use;struct t_boost_status t_boost_status;
Signature · 1 line
2.17.1
Re: [PATCH v4 03/11] lib/power: add changes for host commands/policies
Quoted 8 lines · David Hunt
This patch does a couple of things:
* Adds a new message type for removing policies (PKT_POLICY_REMOVE) Used when we want to remove a previously created policy.
* Adds acore_typebool to the channel packet struct to specify whether the type of core we want to control is cirtual or physical.Signed-off-by David Hunt <[email protected]>---
Signature · 2 lines
Thanks, Anatoly
PATCH v4 4/11 examples/power: add necessary changes to guest app
In reply to David HuntThe changes here are minimal, as the guest app functionality is not changing at all, but there is a new element in the channel_packet struct that needs to have a default set (channel_packet->core_type).
--- examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 1 + 1 file changed, 1 insertion(+)
examples/vm_power_manager/guest_cli/vm_power_cli_guest.c +1 -0
@@ -92,6 +92,7 @@ set_policy_defaults(struct channel_packet *pkt) pkt->timer_policy.hours_to_use_traffic_profile[0 ] =8 ; pkt->timer_policy.hours_to_use_traffic_profile[1 ] =10 ; + pkt->core_type =CORE_TYPE_VIRTUAL ; pkt->workload =LOW ; pkt->policy_to_use =TIME ; pkt->command =PKT_POLICY ;
Signature · 1 line
2.17.1
PATCH v4 5/11 examples/power: add host channel to power manager
In reply to David HuntThis patch adds a fifo channel to the vm_power_manager app through which we can send commands and polices. Intended for sending JSON strings. The fifo is at /tmp/powermonitor/fifo
--- examples/vm_power_manager/channel_manager.c | 109 +++++++++++++++ examples/vm_power_manager/channel_manager.h | 17 +++ examples/vm_power_manager/channel_monitor.c | 142 +++++++++++++++----- examples/vm_power_manager/main.c | 2 + 4 files changed, 236 insertions(+), 34 deletions(-)
examples/vm_power_manager/channel_manager.c +109 -0
@@ -13,6 +13,7 @@#include <sys/queue.h> #include <sys/types.h> +#include <sys/stat.h> #include <sys/socket.h> #include <sys/select.h>
@@ -284,6 +285,38 @@ open_non_blocking_channel(struct channel_info *info)return 0 ; } +static int +open_host_channel (struct channel_info *info) +{ +int flags; + + info->fd =open (info->channel_path,O_RDWR |O_RSYNC ); +if (info->fd ==-1 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error(%s) opening fifo for '%s'\n" , +strerror (errno), + info->channel_path); +return -1 ; + } + +/* Get current flags */ + flags =fcntl (info->fd,F_GETFL ,0 ); +if (flags <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER ,"Error(%s) fcntl get flags socket for" +"'%s'\n" ,strerror (errno), info->channel_path); +return 1 ; + } +/* Set to Non Blocking */ + flags |=O_NONBLOCK ; +if (fcntl (info->fd,F_SETFL , flags) <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER , +"Error(%s) setting non-blocking " +"socket for '%s'\n" , +strerror (errno), info->channel_path); +return -1 ; + } +return 0 ; +} +static int setup_channel_info (struct virtual_machine_info **vm_info_dptr,struct channel_info **chan_info_dptr,unsigned channel_num)
@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, chan_info->channel_num = channel_num; chan_info->priv_info = (void *)vm_info; chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_BINARY ;if (open_non_blocking_channel (chan_info) <0 ) { RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open channel: " "'%s' for VM '%s'\n",
@@ -316,6 +350,42 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr,return 0 ; } +static void +fifo_path (char *dst,unsigned int len) +{ +snprintf (dst, len,"%sfifo" ,CHANNEL_MGR_SOCKET_PATH ); +} + +static int +setup_host_channel_info (struct channel_info **chan_info_dptr, +unsigned int channel_num) +{ +struct channel_info *chan_info = *chan_info_dptr; + + chan_info->channel_num = channel_num; + chan_info->priv_info = (void *)NULL ; + chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_JSON ; + +fifo_path (chan_info->channel_path,sizeof (chan_info->channel_path)); + +if (open_host_channel (chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could not open host channel: " +"'%s'\n" , + chan_info->channel_path); +return -1 ; + } +if (add_channel_to_monitor (&chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could add channel: " +"'%s' to epoll ctl\n" , + chan_info->channel_path); +return -1 ; + + } + chan_info->status =CHANNEL_MGR_CHANNEL_CONNECTED ; +return 0 ; +} +int add_all_channels (const char *vm_name) {
@@ -470,6 +540,45 @@ add_channels(const char *vm_name, unsigned *channel_list,return num_channels_enabled; } +int +add_host_channel (void ) +{ +struct channel_info *chan_info; +char socket_path[PATH_MAX ]; +int num_channels_enabled =0 ; +int ret; + +fifo_path (socket_path,sizeof (socket_path)); + + ret =mkfifo (socket_path,0660 ); +if ((errno !=EEXIST ) && (ret <0 )) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Cannot create fifo '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + +if (access (socket_path,F_OK ) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Channel path '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + chan_info =rte_malloc (NULL ,sizeof (*chan_info),0 ); +if (chan_info ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for " +"channel '%s'\n" , socket_path); +return 0 ; + } +snprintf (chan_info->channel_path, +sizeof (chan_info->channel_path),"%s" , socket_path); +if (setup_host_channel_info (&chan_info,0 ) <0 ) { +rte_free (chan_info); +return 0 ; + } + num_channels_enabled++; + +return num_channels_enabled; +} +int remove_channel (struct channel_info **chan_info_dptr) {
examples/vm_power_manager/channel_manager.h +17 -0
@@ -54,6 +54,13 @@ enum channel_status { CHANNEL_MGR_CHANNEL_DISCONNECTED = 0,CHANNEL_MGR_CHANNEL_DISABLED , CHANNEL_MGR_CHANNEL_PROCESSING}; +/* Communication Channel Type */ +enum channel_type { +CHANNEL_TYPE_BINARY =0 , +CHANNEL_TYPE_INI , +CHANNEL_TYPE_JSON +}; +/* VM libvirt(qemu/KVM) connection status */ enum vm_status {CHANNEL_MGR_VM_INACTIVE =0 ,CHANNEL_MGR_VM_ACTIVE };
@@ -66,6 +73,7 @@ struct channel_info {volatile uint32_t status;/**< Connection status(enum channel_status) */ int fd;/**< AF_UNIX socket fd */ unsigned channel_num;/**< CHANNEL_MGR_SOCKET_PATH/<vm_name>.channel_num */ +enum channel_type type;/**< Binary, ini, json, etc. */ void *priv_info;/**< Pointer to private info, do not modify */ };
@@ -226,6 +234,15 @@ int add_all_channels(const char *vm_name);int add_channels (const char *vm_name,unsigned *channel_list,unsigned num_channels); +/** +* Set up a fifo by which host applications can send command an policies +* through a fifo to the vm_power_manager +* +* @return +* - 0 for success +*/ +int add_host_channel (void ); +/** * Remove a channel definition from the channel manager. This must only be * called from the channel monitor thread.
examples/vm_power_manager/channel_monitor.c +108 -34
221 lines not on this page · raw message
examples/vm_power_manager/main.c +2 -0
@@ -421,6 +421,8 @@ main(int argc, char **argv)return -1 ; } +add_host_channel (); +printf ("Running core monitor on lcore id %d\n" , lcore_id);rte_eal_remote_launch (run_core_monitor,NULL , lcore_id);
Signature · 1 line
2.17.1
Re: [PATCH v4 05/11] examples/power: add host channel to power manager
Quoted 6 lines · David Hunt
This patch adds a fifo channel to the
vm_power_managerapp through which we can send commands and polices. Intended for sending JSON strings. The fifo is at/tmp/powermonitor/fifoSigned-off-by David Hunt <[email protected]>---
Signature · 2 lines
Thanks, Anatoly
PATCH v4 6/11 examples/power: increase allowed number of clients
In reply to David HuntNow that we're handling host policies, containers and virtual machines, we'll rename MAX_VMS to MAX_CLIENTS, and increase from 4 to 64
--- examples/vm_power_manager/channel_manager.h | 4 ++-- examples/vm_power_manager/channel_monitor.c | 10 +++++----- 2 files changed, 7 insertions(+), 7 deletions(-)
examples/vm_power_manager/channel_manager.h +2 -2
@@ -37,7 +37,7 @@ struct sockaddr_un _sockaddr_un;#define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path)#endif -#define MAX_VMS 4 +#define MAX_CLIENTS 64#define MAX_VCPUS 20
@@ -47,7 +47,7 @@ struct libvirt_vm_info {uint8_t num_cpus; }; -struct libvirt_vm_info lvm_info[MAX_VMS ]; +struct libvirt_vm_info lvm_info[MAX_CLIENTS ];/* Communication Channel Status */ enum channel_status {CHANNEL_MGR_CHANNEL_DISCONNECTED =0 ,CHANNEL_MGR_CHANNEL_CONNECTED ,
examples/vm_power_manager/channel_monitor.c +5 -5
@@ -41,7 +41,7 @@ static volatile unsigned run_loop = 1;static int global_event_fd;static unsigned int policy_is_set;static struct epoll_event *global_events_list; -static struct policy policies[MAX_VMS ]; +static struct policy policies[MAX_CLIENTS ];void channel_monitor_exit (void ) {
@@ -199,7 +199,7 @@ update_policy(struct channel_packet *pkt)RTE_LOG (INFO ,CHANNEL_MONITOR ,"Applying policy for %s\n" , pkt->vm_name); -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) {/* Copy the contents of *pkt into the policy.pkt */ policies[i].pkt = *pkt;
@@ -214,7 +214,7 @@ update_policy(struct channel_packet *pkt) } }if (!updated) { -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (policies[i].enabled ==0 ) { policies[i].pkt = *pkt;get_pcpu_to_control (&policies[i]);
@@ -238,7 +238,7 @@ remove_policy(struct channel_packet *pkt __rte_unused)* Disabling the policy is simply a case of setting * enabled to 0 */ -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) { policies[i].enabled =0 ;return 0 ;
@@ -609,7 +609,7 @@ run_channel_monitor(void)if (policy_is_set) {int j; -for (j =0 ; j <MAX_VMS ; j++) { +for (j =0 ; j <MAX_CLIENTS ; j++) {if (policies[j].enabled ==1 )apply_policy (&policies[j]); }
Signature · 1 line
2.17.1
Re: [PATCH v4 06/11] examples/power: increase allowed number of clients
Quoted 5 lines · David Hunt
Now that we're handling host policies, containers and virtual machines, we'll rename
MAX_VMStoMAX_CLIENTS, and increase from 4 to 64Signed-off-by David Hunt <[email protected]>---
Signature · 2 lines
Thanks, Anatoly
PATCH v4 7/11 examples/power: add json string handling
In reply to David HuntAdd JSON string handling to vm_power_manager for JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, the vm_power_manager user guide documentation updates.
This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
--- examples/vm_power_manager/Makefile | 6 + examples/vm_power_manager/channel_monitor.c | 269 ++++++++++++++++++-- 2 files changed, 250 insertions(+), 25 deletions(-)
examples/vm_power_manager/Makefile +6 -0
@@ -31,6 +31,12 @@ CFLAGS += $(WERROR_FLAGS) LDLIBS += -lvirt +JANSSON := $(shell pkg-config --exists jansson; echo $$?) +ifeq ($(JANSSON), 0) +LDLIBS += $(shell pkg-config --libs jansson) +CFLAGS += -DUSE_JANSSON +endif + ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
examples/vm_power_manager/channel_monitor.c +244 -25
304 lines not on this page · raw message
Signature · 1 line
2.17.1
Re: [PATCH v4 07/11] examples/power: add json string handling
Quoted 11 lines · David Hunt
Add JSON string handling to
vm_power_managerfor JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, thevm_power_manageruser guide documentation updates.This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
Signed-off-by David Hunt <[email protected]>---
Signature · 2 lines
Thanks, Anatoly
PATCH v4 8/11 examples/power: clean up verbose messages
In reply to David HuntSome messages appearing several times a second, removing as they are unnecessary. Other less severe messages change from INFO to DEBUG
--- examples/vm_power_manager/channel_monitor.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-)
examples/vm_power_manager/channel_monitor.c +5 -14
@@ -259,7 +259,7 @@ get_pcpu_to_control(struct policy *pol) ci =get_core_info (); -RTE_LOG (INFO ,CHANNEL_MONITOR , +RTE_LOG (DEBUG ,CHANNEL_MONITOR ,"Looking for pcpu for %s\n" , pol->pkt.vm_name);/*
@@ -426,8 +426,6 @@ apply_traffic_profile(struct policy *pol) diff =get_pkt_diff (pol); -RTE_LOG (INFO ,CHANNEL_MONITOR ,"Applying traffic profile\n" ); -if (diff >= (pol->pkt.traffic_policy.max_max_packet_thresh)) {for (count =0 ; count < pol->pkt.num_vcpu; count++) {if (pol->core_share[count].status !=1 )
@@ -471,9 +469,6 @@ apply_time_profile(struct policy *pol)if (pol->core_share[count].status !=1 ) {power_manager_scale_core_max ( pol->core_share[count].pcpu); -RTE_LOG (INFO ,CHANNEL_MONITOR , -"Scaling up core %d to max\n" , - pol->core_share[count].pcpu); } }break ;
@@ -483,9 +478,6 @@ apply_time_profile(struct policy *pol)if (pol->core_share[count].status !=1 ) {power_manager_scale_core_min ( pol->core_share[count].pcpu); -RTE_LOG (INFO ,CHANNEL_MONITOR , -"Scaling down core %d to min\n" , - pol->core_share[count].pcpu); } }break ;
@@ -547,8 +539,6 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info)if (chan_info ==NULL )return -1 ; -RTE_LOG (INFO ,CHANNEL_MONITOR ,"Processing Request %s\n" , pkt->vm_name); -if (rte_atomic32_cmpset (&(chan_info->status),CHANNEL_MGR_CHANNEL_CONNECTED ,CHANNEL_MGR_CHANNEL_PROCESSING ) ==0 )return -1 ;
@@ -617,8 +607,8 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info) }if (pkt->command ==PKT_POLICY ) { -RTE_LOG (INFO ,CHANNEL_MONITOR , -"\nProcessing Policy request\n" ); +RTE_LOG (INFO ,CHANNEL_MONITOR ,"Processing policy request %s\n" , + pkt->vm_name);update_policy (pkt); policy_is_set =1 ; }
@@ -802,7 +792,8 @@ run_channel_monitor(void) global_events_list[i].data.ptr;if ((global_events_list[i].events &EPOLLERR ) || (global_events_list[i].events &EPOLLHUP )) { -RTE_LOG (DEBUG ,CHANNEL_MONITOR ,"Remote closed connection for " +RTE_LOG (INFO ,CHANNEL_MONITOR , +"Remote closed connection for " "channel '%s'\n" , chan_info->channel_path);remove_channel (&chan_info);
Signature · 1 line
2.17.1
Re: [PATCH v4 08/11] examples/power: clean up verbose messages
Quoted 5 lines · David Hunt
Some messages appearing several times a second, removing as they are unnecessary. Other less severe messages change from INFO to DEBUG
Signed-off-by David Hunt <[email protected]>---
Signature · 2 lines
Thanks, Anatoly
PATCH v4 9/11 examples/power: add meson/ninja build support
In reply to David HuntAdd meson.build in vm_power_manager and the guest_cli subdirectory. Building can be achieved by going to the build directory, and using
meson configure -Dexamples=vm_power_manager,vm_power_manager/guest_cli
Then, when ninja is invoked, it will build dpdk-vm_power_manger and dpdk-guest_cli
Work still needs to be done on the meson build system to handles the case where the target list of example apps is defined as 'all'. That will come in a future patch.
--- .../vm_power_manager/guest_cli/meson.build | 21 +++++++++++ examples/vm_power_manager/meson.build | 37 ++++++++++++++++++- 2 files changed, 56 insertions(+), 2 deletions(-) create mode 100644 examples/vm_power_manager/guest_cli/meson.build
examples/vm_power_manager/guest_cli/meson.build new file +21 -0
@@ -0,0 +1,21 @@ +# SPDX-License-Identifier: BSD-3-Clause +# Copyright(c) 2018 Intel Corporation + +# meson file, for building this example as part of a main DPDK build. +# +# To build this example as a standalone application with an already-installed +# DPDK instance, use 'make' + +# Setting the name here because the default name will conflict with the +# vm_power_manager app because of the way the directories are parsed. +name = 'guest_cli' + +deps += ['power'] + +sources = files( + 'main.c', 'parse.c', 'vm_power_cli_guest.c' +) + +opt_dep = cc.find_library('virt', required : false) +build = opt_dep.found() +ext_deps += opt_dep
examples/vm_power_manager/meson.build +35 -2
@@ -6,5 +6,38 @@ # To build this example as a standalone application with an already-installed # DPDK instance, use 'make' -# Example app currently unsupported by meson build -build = false +if dpdk_conf.has('RTE_LIBRTE_BNXT_PMD') + deps += ['pmd_bnxt'] +endif + +if dpdk_conf.has('RTE_LIBRTE_I40E_PMD') + deps += ['pmd_i40e'] +endif + +if dpdk_conf.has('RTE_LIBRTE_IXGBE_PMD') + deps += ['pmd_ixgbe'] +endif + +deps += ['power'] + + +sources = files( + 'channel_manager.c', 'channel_monitor.c', 'main.c', 'parse.c', 'power_manager.c', 'vm_power_cli.c' +) + +# If we're on X86, pull in the x86 code for the branch monitor algo. +if dpdk_conf.has('RTE_ARCH_X86_64') + sources += files('oob_monitor_x86.c') +else + sources += files('oob_monitor_nop.c') +endif + +opt_dep = cc.find_library('virt', required : false) +build = opt_dep.found() +ext_deps += opt_dep + +opt_dep = dependency('jansson', required : false) +if opt_dep.found() + ext_deps += opt_dep + cflags += '-DUSE_JANSSON' +endif
Signature · 1 line
2.17.1
PATCH v4 10/11 doc/vm_power_manager: add JSON interface API info
In reply to David HuntAlso added meson/ninja build info
--- .../sample_app_ug/vm_power_management.rst | 272 +++++++++++++++++- 1 file changed, 270 insertions(+), 2 deletions(-)
doc/guides/sample_app_ug/vm_power_management.rst +270 -2
@@ -199,7 +199,7 @@ see :doc:`compiling`. The application is located in the ``vm_power_manager`` sub-directory. -To build just the ``vm_power_manager`` application: +To build just the ``vm_power_manager`` application using ``make``: .. code-block:: console
@@ -208,6 +208,22 @@ To build just the ``vm_power_manager`` application: cd ${RTE_SDK}/examples/vm_power_manager/ make +The resulting binary will be ${RTE_SDK}/build/examples/vm_power_manager + +To build just the ``vm_power_manager`` application using ``meson/ninja``: + +.. code-block:: console + + export RTE_SDK=/path/to/rte_sdk + cd ${RTE_SDK} + meson build + cd build + ninja + meson configure -Dexamples=vm_power_manager + ninja + +The resulting binary will be ${RTE_SDK}/build/examples/dpdk-vm_power_manager + Running ~~~~~~~
@@ -337,6 +353,242 @@ monitoring of branch ratio on cores doing busy polling via PMDs. and will need to be adjusted for different workloads. + +JSON API +~~~~~~~~ + +In addition to the command line interface for host command and a virtio-serial +interface for VM power policies, there is also a JSON interface through which +power commands and policies can be sent. This functionality adds a dependency +on the Jansson library, and the Jansson development package must be installed +on the system before the JSON parsing functionality is included in the app. +This is achieved by: + + .. code-block:: console + + apt-get install libjansson-dev + +The command and package name may be different depending on your operating +system. It's worth noting that the app will successfully build without this +package present, but a warning is shown during compilation, and the JSON +parsing functionality will not be present in the app. + +Sending a command or policy to the power manager application is achieved by +simply opening a fifo file, writing a JSON string to that fifo, and closing +the file. + +The fifo is at /tmp/powermonitor/fifo + +The jason string can be a policy or instruction, and takes the following +format: + + .. code-block:: console + + {"packet_type": { + "pair_1": value, + "pair_2": value + }} + +The 'packet_type' header can contain one of two values, depending on +whether a policy or power command is being sent. The two possible values are +"policy" and "instruction", and the expected name-value pairs is different +depending on which type is being sent. + +The pairs are the format of standard JSON name-value pairs. The value type +varies between the different name/value pairs, and may be intgers, strings, +arrays, etc. Examples of policies follow later in this document. The allowed +names and value types are as follows: + + +:Pair Name: "name" +:Description: Name of the VM or Host. Allows the parser to associate the + policy with the relevant VM or Host OS. +:Type: string +:Values: any valid string +:Required: yes +:Example: + + .. code-block:: console + + ""name", "ubuntu2" + + +:Pair Name: "command" +:Description: The type of packet we're sending to the power manager. We can be + creating or destroying a policy, or sending a direct command to adjust + the frequency of a core, similar to the command line interface. +:Type: string +:Values: + + :"CREATE": used when creating a new policy, + :"DESTROY": used when removing a policy, + :"POWER": used when sending an immediate command, max, min, etc. +:Required: yes +:Example: + + .. code-block:: console + + "command", "CREATE" + + +:Pair Name: "policy_type" +:Description: Type of policy to apply. Please see vm_power_manager documentation + for more information on the types of policies that may be used. +:Type: string +:Values: + + :"TIME": Time-of-day policy. Frequencies of the relevant cores are + scaled up/down depending on busy and quiet hours. + :"TRAFFIC": This policy takes statistics from the NIC and scales up + and down accordingly. + :"WORKLOAD": This policy looks at how heavily loaded the cores are, + and scales up and down accordingly. + :"BRANCH_RATIO": This out-of-band policy can look at the ratio between + branch hits and misses on a core, and is useful for detecting + how much packet processing a core is doing. +:Required: only for CREATE/DESTROY command +:Example: + + .. code-block:: console + + "policy_type", "TIME" + +:Pair Name: "busy_hours" +:Description: The hours of the day in which we scale up the cores for busy + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console + + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ] + +:Pair Name: "quiet_hours" +:Description: The hours of the day in which we scale down the cores for quiet + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: console + + "quiet_hours":[ 2, 3, 4, 5, 6 ] + +:Pair Name: "avg_packet_thresh" +:Description: Threshold below which the frequency will be set to min for + the TRAFFIC policy. If the traffic rate is above this and below max, the + frequency will be set to medium. +:Type: integer +:Values: The number of packets below which the TRAFFIC policy applies the + minimum frequency, or medium frequency if between avg and max thresholds. +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: console + + "avg_packet_thresh": 100000 + +:Pair Name: "max_packet_thresh" +:Description: Threshold above which the frequency will be set to max for + the TRAFFIC policy +:Type: integer +:Values: The number of packets per interval above which the TRAFFIC policy + applies the maximum frequency +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: console + + "max_packet_thresh": 500000 + +:Pair Name: "core_list" +:Description: The cores to which to apply the policy. +:Type: array of integers +:Values: array with list of virtual CPUs. +:Required: only policy CREATE/DESTROY +:Example: + + .. code-block:: console + + "core_list":[ 10, 11 ] + +:Pair Name: "unit" +:Description: the type of power operation to apply in the command +:Type: string +:Values: + + :"SCALE_MAX": Scale frequency of this core to maximum + :"SCALE_MIN": Scale frequency of this core to minimum + :"SCALE_UP": Scale up frequency of this core + :"SCALE_DOWN": Scale down frequency of this core + :"ENABLE_TURBO": Enable Turbo Boost for this core + :"DISABLE_TURBO": Disable Turbo Boost for this core +:Required: only for POWER instruction +:Example: + + .. code-block:: console + + "unit", "SCALE_MAX" + +:Pair Name: "resource_id" +:Description: The core to which to apply the power command. +:Type: integer +:Values: valid core id for VM or host OS. +:Required: only POWER instruction +:Example: + + .. code-block:: console + + "resource_id": 10 + +JSON API Examples +~~~~~~~~~~~~~~~~~ + +Profile create example: + + .. code-block:: console + + {"policy": { + "name": "ubuntu", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11 ] + }} + +Profile destroy example: + + .. code-block:: console + + {"profile": { + "name": "ubuntu", + "command": "destroy", + }} + +Power command example: + + .. code-block:: console + + {"command": { + "name": "ubuntu", + "unit": "SCALE_MAX", + "resource_id": 10 + }} + +To send a JSON string to the Power Manager application, simply paste the +example JSON string into a text file and cat it into the fifo: + + .. code-block:: console + + cat file.json >/tmp/powermonitor/fifo + +The console of the Power Manager application should indicate the command that +was just received via the fifo. + Compiling and Running the Guest Applications --------------------------------------------
@@ -366,7 +618,7 @@ For compiling and running l3fwd-power, see :doc:`l3_forward_power_man`. The application is located in the ``guest_cli`` sub-directory under ``vm_power_manager``. -To build just the ``guest_vm_power_manager`` application: +To build just the ``guest_vm_power_manager`` application using ``make``: .. code-block:: console
@@ -375,6 +627,22 @@ To build just the ``guest_vm_power_manager`` application: cd ${RTE_SDK}/examples/vm_power_manager/guest_cli/ make +The resulting binary will be ${RTE_SDK}/build/examples/guest_cli + +To build just the ``vm_power_manager`` application using ``meson/ninja``: + +.. code-block:: console + + export RTE_SDK=/path/to/rte_sdk + cd ${RTE_SDK} + meson build + cd build + ninja + meson configure -Dexamples=vm_power_manager/guest_cli + ninja + +The resulting binary will be ${RTE_SDK}/build/examples/guest_cli + Running ~~~~~~~
Signature · 1 line
2.17.1
Re: [PATCH v4 10/11] doc/vm_power_manager: add JSON interface API info
Quoted 6 lines
Also added meson/ninja build info
Signed-off-by David Hunt <[email protected]>--- .../sample_app_ug/vm_power_management.rst | 272+++++++++++++++++-
PATCH v4 11/11 examples/power: add json example files
In reply to David HuntThis patch provides some example files in the json_examples sub-directory for sending to the fifo.
--- examples/vm_power_manager/json_examples/README | 6 ++++++ examples/vm_power_manager/json_examples/create.json | 8 ++++++++ examples/vm_power_manager/json_examples/destroy.json | 4 ++++ examples/vm_power_manager/json_examples/set_core_max.json | 6 ++++++ examples/vm_power_manager/json_examples/set_core_min.json | 6 ++++++ 5 files changed, 30 insertions(+) create mode 100644 examples/vm_power_manager/json_examples/README create mode 100644 examples/vm_power_manager/json_examples/create.json create mode 100644 examples/vm_power_manager/json_examples/destroy.json create mode 100644 examples/vm_power_manager/json_examples/set_core_max.json create mode 100644 examples/vm_power_manager/json_examples/set_core_min.json
examples/vm_power_manager/json_examples/README new file +6 -0
@@ -0,0 +1,6 @@ +Sample files for sending to the vm_power_manager through the fifo. + +Simply cat the file to /tmp/powermonitor/fifo when the vm_power_manager +application is running. + +E.g. cat create.json >/tmp/powermonitor/fifo
examples/vm_power_manager/json_examples/create.json new file +8 -0
@@ -0,0 +1,8 @@ +{"policy": { + "name": "policy-1", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11, 12 ] +}}
examples/vm_power_manager/json_examples/destroy.json new file +4 -0
@@ -0,0 +1,4 @@ +{"policy": { + "name": "policy-1", + "command": "destroy" +}}
examples/vm_power_manager/json_examples/set_core_max.json new file +6 -0
@@ -0,0 +1,6 @@ +{"instruction": { + "name": "set_power", + "command": "power", + "unit": "SCALE_MAX", + "resource_id": 10 +}}
examples/vm_power_manager/json_examples/set_core_min.json new file +6 -0
@@ -0,0 +1,6 @@ +{"instruction": { + "name": "set_power", + "command": "power", + "unit": "SCALE_MIN", + "resource_id": 10 +}}
Signature · 1 line
2.17.1
Re: [PATCH v4 11/11] examples/power: add json example files
Hi Dave,
Feel like this part is not needed in the patch as you have this already in the documentation, People can just copy and paste the examples from the docs, so we don't need to maintain two things.
Thanks,
Marko K.
Re: [PATCH v4 11/11] examples/power: add json example files
Good point. There's also a couple of tiny niggles I'd like to resolve in patch 10 of the set, so I'll re-spin in v5.
-----Original Message-----
From: Kovacevic, Marko
Sent: Wednesday, 26 September, 2018 4:58 PM
To: Hunt, David <[email protected]>; [email protected]
Cc: Mcnamara, John <[email protected]>; [email protected]; Yao, Lei A <[email protected]>; Burakov, Anatoly <[email protected]>; Hunt, David <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v4 11/11] examples/power: add json example files
Hi Dave,
Feel like this part is not needed in the patch as you have this already in the documentation, People can just copy and paste the examples from the docs, so we don't need to maintain two things.
Thanks,
Marko K.
v5 cover add json power policy interface for containers
In reply to David HuntThe current vm_power_manager example app has the capability to accept power policies from virtual machines via virtio-serial channels. These power policies allow a virtual machine to give information to the power manager to allow the power manager take care of the power management of the virtual machine based on the information in the policy.
This power policy functionality is limited to virtual machines sending the policies to the power manager (which runs in the Host OS), and a solution was needed for additional methods of sending power policies to the power manager app.
The main use-case for this modification is for containers and host applications that wish to send polices to the power manager.
This patchset adds the capability to send power polices and power commands to the vm_power_manager app via JSON strings through a fifo on the file system.
For example, given the following file, policy.json:
{"policy": {
"name": "ubuntu2",
"command": "create",
"policy_type": "TIME",
"busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ],
"quiet_hours":[ 2, 3, 4, 5, 6 ],
"core_list":[ 11, 12, 13 ]
}}
Then running the command:
cat policy.json >/tmp/powermonitor/fifo
The policy is sent to the vm_power_manager. The power manager app then parses the JSON data, and inserts the policy into the array of policies.
Part of the patch series contains documentation updates to give all the details of the valid name-value pairs, the data types, etc.
Patch v2:
* Fixed review comments from Stephen Hemminger and Lei A Yao.
* Added a check in the Makefile for libjansson-dev. Will Warn user and build without JSON functionality if not present, will build including JSON functionality if it is present.
Patch v3:
* Added meson/ninja support for vm_power_manager and guest_cli apps
* Fixed compilation issue with guest_cli app
Patch v4:
* Split out some unrelated changes to separate patches in the set
* Some changes out of review by Anatoly (Thanks!)
Patch v5:
* Removed the directory with JSON examples, as they already exist in the documentation.
* Fixed some typos and formatting issues in the documentation.
* Changed the JSON examples in the documentation to 'javascript' causing the syntax to be highlighted nicely.
* Inherited the Acks from previous version.
[01/10] examples/power: add checks around hypervisor [02/10] examples/power: allow for number of vms to be zero [03/10] lib/power: add changes for host commands/policies [04/10] examples/power: add necessary changes to guest app [05/10] examples/power: add host channel to power manager [06/10] examples/power: increase allowed number of clients [07/10] examples/power: add json string handling [08/10] examples/power: clean up verbose messages [09/10] examples/power: add meson/ninja build support [10/10] doc/vm_power_manager: add JSON interface API info
PATCH v5 1/10 examples/power: add checks around hypervisor
Allow vm_power_manager to run without requiring qemu to be present on the machine. This will be required for instances where the JSON interface is used for commands and polices, without any VMs present. A use case for this is a container enviromnent.
--- examples/vm_power_manager/channel_manager.c | 71 +++++++++++++-------- 1 file changed, 43 insertions(+), 28 deletions(-)
examples/vm_power_manager/channel_manager.c +43 -28
@@ -43,7 +43,8 @@ static unsigned char *global_cpumaps;static virVcpuInfo *global_vircpuinfo;static size_t global_maplen; -static unsigned global_n_host_cpus; +static unsigned int global_n_host_cpus; +static bool global_hypervisor_available;/* * Represents a single Virtual Machine
@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) {struct virtual_machine_info *vm_info = (struct virtual_machine_info *)chan_info->priv_info; -return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); + +if (global_hypervisor_available && (vm_info !=NULL )) +return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); +else +return 0 ; } static inline int
@@ -559,6 +564,8 @@ get_all_vm(int *num_vm, int *num_vcpu)VIR_CONNECT_LIST_DOMAINS_PERSISTENT ;unsigned int domain_flag =VIR_DOMAIN_VCPU_CONFIG ; +if (!global_hypervisor_available) +return ;memset (global_cpumaps,0 ,CHANNEL_CMDS_MAX_CPUS *global_maplen);if (virNodeGetInfo (global_vir_conn_ptr, &node_info)) {
@@ -768,38 +775,42 @@ connect_hypervisor(const char *path) }return 0 ; } -int -channel_manager_init (const char *path) +channel_manager_init(const char *path __rte_unused) {virNodeInfo info;LIST_INIT (&vm_list_head);if (connect_hypervisor (path) <0 ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); -return -1 ; - } - - global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + global_n_host_cpus =64 ; + global_hypervisor_available =0 ; +RTE_LOG (INFO ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); + }else { + global_hypervisor_available =1 ; + + global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + + global_vircpuinfo =rte_zmalloc (NULL , +sizeof (*global_vircpuinfo) * +CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); +if (global_vircpuinfo ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); + goto error; + } + global_cpumaps =rte_zmalloc (NULL , +CHANNEL_CMDS_MAX_CPUS * global_maplen, +RTE_CACHE_LINE_SIZE ); +if (global_cpumaps ==NULL ) + goto error; - global_vircpuinfo =rte_zmalloc (NULL ,sizeof (*global_vircpuinfo) * -CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); -if (global_vircpuinfo ==NULL ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); - goto error; - } - global_cpumaps =rte_zmalloc (NULL ,CHANNEL_CMDS_MAX_CPUS * global_maplen, -RTE_CACHE_LINE_SIZE ); -if (global_cpumaps ==NULL ) { - goto error; +if (virNodeGetInfo (global_vir_conn_ptr, &info)) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); + goto error; + } + global_n_host_cpus = (unsigned int )info.cpus; } -if (virNodeGetInfo (global_vir_conn_ptr, &info)) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); - goto error; - } - global_n_host_cpus = (unsigned )info.cpus;if (global_n_host_cpus >CHANNEL_CMDS_MAX_CPUS ) { RTE_LOG(WARNING, CHANNEL_MANAGER, "The number of host CPUs(%u) exceeds the "
@@ -811,7 +822,8 @@ channel_manager_init(const char *path)return 0 ; error: -disconnect_hypervisor (); +if (global_hypervisor_available) +disconnect_hypervisor ();return -1 ; }
@@ -838,7 +850,10 @@ channel_manager_exit(void)rte_free (vm_info); } -rte_free (global_cpumaps); -rte_free (global_vircpuinfo); -disconnect_hypervisor (); +if (global_hypervisor_available) { +/* Only needed if hypervisor available */ +rte_free (global_cpumaps); +rte_free (global_vircpuinfo); +disconnect_hypervisor (); + } }
Signature · 1 line
2.17.1
PATCH v5 2/10 examples/power: allow for number of vms to be zero
In reply to David HuntPreviously the vm_power_manager app required to have some vms defined, so the call to get_all_vm() always set the noVms variable. Now we're accepting policies from the host OS (without any VMs defined), so it is now valid to have zero VMs. This patch initialises the relevant variables to zero just in case the call to get_all_vms() does not find any, so could return with the variables uninitialised.
--- examples/vm_power_manager/channel_monitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
examples/vm_power_manager/channel_monitor.c +1 -1
@@ -66,7 +66,7 @@ static void core_share_status(int pNo) { -int noVms, noVcpus, z, x, t; +int noVms =0 , noVcpus =0 , z, x, t;get_all_vm (&noVms, &noVcpus);
Signature · 1 line
2.17.1
PATCH v5 3/10 lib/power: add changes for host commands/policies
In reply to David HuntThis patch does a couple of things:
* Adds a new message type for removing policies (PKT_POLICY_REMOVE) Used when we want to remove a previously created policy.
* Adds a core_type bool to the channel packet struct to specify whether the type of core we want to control is cirtual or physical.
--- lib/librte_power/channel_commands.h | 5 +++++ 1 file changed, 5 insertions(+)
lib/librte_power/channel_commands.h +5 -0
@@ -19,6 +19,7 @@ extern "C" {#define CPU_POWER 1#define CPU_POWER_CONNECT 2#define PKT_POLICY 3 +#define PKT_POLICY_REMOVE 4/* CPU Power Command Scaling */ #define CPU_POWER_SCALE_UP 1
@@ -58,6 +59,9 @@ struct traffic {uint32_t max_max_packet_thresh; }; +#define CORE_TYPE_VIRTUAL 0 +#define CORE_TYPE_PHYSICAL 1 +struct channel_packet {uint64_t resource_id;/**< core_num, device */ uint32_t unit;/**< scale down/up/min/max */
@@ -70,6 +74,7 @@ struct channel_packet {uint8_t vcpu_to_control[MAX_VCPU_PER_VM ];uint8_t num_vcpu;struct timer_profile timer_policy; +bool core_type;enum workload workload;enum policy_to_use policy_to_use;struct t_boost_status t_boost_status;
Signature · 1 line
2.17.1
PATCH v5 4/10 examples/power: add necessary changes to guest app
In reply to David HuntThe changes here are minimal, as the guest app functionality is not changing at all, but there is a new element in the channel_packet struct that needs to have a default set (channel_packet->core_type).
--- examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 1 + 1 file changed, 1 insertion(+)
examples/vm_power_manager/guest_cli/vm_power_cli_guest.c +1 -0
@@ -92,6 +92,7 @@ set_policy_defaults(struct channel_packet *pkt) pkt->timer_policy.hours_to_use_traffic_profile[0 ] =8 ; pkt->timer_policy.hours_to_use_traffic_profile[1 ] =10 ; + pkt->core_type =CORE_TYPE_VIRTUAL ; pkt->workload =LOW ; pkt->policy_to_use =TIME ; pkt->command =PKT_POLICY ;
Signature · 1 line
2.17.1
PATCH v5 5/10 examples/power: add host channel to power manager
In reply to David HuntThis patch adds a fifo channel to the vm_power_manager app through which we can send commands and polices. Intended for sending JSON strings. The fifo is at /tmp/powermonitor/fifo
--- examples/vm_power_manager/channel_manager.c | 109 +++++++++++++++ examples/vm_power_manager/channel_manager.h | 17 +++ examples/vm_power_manager/channel_monitor.c | 142 +++++++++++++++----- examples/vm_power_manager/main.c | 2 + 4 files changed, 236 insertions(+), 34 deletions(-)
examples/vm_power_manager/channel_manager.c +109 -0
@@ -13,6 +13,7 @@#include <sys/queue.h> #include <sys/types.h> +#include <sys/stat.h> #include <sys/socket.h> #include <sys/select.h>
@@ -284,6 +285,38 @@ open_non_blocking_channel(struct channel_info *info)return 0 ; } +static int +open_host_channel (struct channel_info *info) +{ +int flags; + + info->fd =open (info->channel_path,O_RDWR |O_RSYNC ); +if (info->fd ==-1 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error(%s) opening fifo for '%s'\n" , +strerror (errno), + info->channel_path); +return -1 ; + } + +/* Get current flags */ + flags =fcntl (info->fd,F_GETFL ,0 ); +if (flags <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER ,"Error(%s) fcntl get flags socket for" +"'%s'\n" ,strerror (errno), info->channel_path); +return 1 ; + } +/* Set to Non Blocking */ + flags |=O_NONBLOCK ; +if (fcntl (info->fd,F_SETFL , flags) <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER , +"Error(%s) setting non-blocking " +"socket for '%s'\n" , +strerror (errno), info->channel_path); +return -1 ; + } +return 0 ; +} +static int setup_channel_info (struct virtual_machine_info **vm_info_dptr,struct channel_info **chan_info_dptr,unsigned channel_num)
@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, chan_info->channel_num = channel_num; chan_info->priv_info = (void *)vm_info; chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_BINARY ;if (open_non_blocking_channel (chan_info) <0 ) { RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open channel: " "'%s' for VM '%s'\n",
@@ -316,6 +350,42 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr,return 0 ; } +static void +fifo_path (char *dst,unsigned int len) +{ +snprintf (dst, len,"%sfifo" ,CHANNEL_MGR_SOCKET_PATH ); +} + +static int +setup_host_channel_info (struct channel_info **chan_info_dptr, +unsigned int channel_num) +{ +struct channel_info *chan_info = *chan_info_dptr; + + chan_info->channel_num = channel_num; + chan_info->priv_info = (void *)NULL ; + chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_JSON ; + +fifo_path (chan_info->channel_path,sizeof (chan_info->channel_path)); + +if (open_host_channel (chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could not open host channel: " +"'%s'\n" , + chan_info->channel_path); +return -1 ; + } +if (add_channel_to_monitor (&chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could add channel: " +"'%s' to epoll ctl\n" , + chan_info->channel_path); +return -1 ; + + } + chan_info->status =CHANNEL_MGR_CHANNEL_CONNECTED ; +return 0 ; +} +int add_all_channels (const char *vm_name) {
@@ -470,6 +540,45 @@ add_channels(const char *vm_name, unsigned *channel_list,return num_channels_enabled; } +int +add_host_channel (void ) +{ +struct channel_info *chan_info; +char socket_path[PATH_MAX ]; +int num_channels_enabled =0 ; +int ret; + +fifo_path (socket_path,sizeof (socket_path)); + + ret =mkfifo (socket_path,0660 ); +if ((errno !=EEXIST ) && (ret <0 )) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Cannot create fifo '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + +if (access (socket_path,F_OK ) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Channel path '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + chan_info =rte_malloc (NULL ,sizeof (*chan_info),0 ); +if (chan_info ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for " +"channel '%s'\n" , socket_path); +return 0 ; + } +snprintf (chan_info->channel_path, +sizeof (chan_info->channel_path),"%s" , socket_path); +if (setup_host_channel_info (&chan_info,0 ) <0 ) { +rte_free (chan_info); +return 0 ; + } + num_channels_enabled++; + +return num_channels_enabled; +} +int remove_channel (struct channel_info **chan_info_dptr) {
examples/vm_power_manager/channel_manager.h +17 -0
@@ -54,6 +54,13 @@ enum channel_status { CHANNEL_MGR_CHANNEL_DISCONNECTED = 0,CHANNEL_MGR_CHANNEL_DISABLED , CHANNEL_MGR_CHANNEL_PROCESSING}; +/* Communication Channel Type */ +enum channel_type { +CHANNEL_TYPE_BINARY =0 , +CHANNEL_TYPE_INI , +CHANNEL_TYPE_JSON +}; +/* VM libvirt(qemu/KVM) connection status */ enum vm_status {CHANNEL_MGR_VM_INACTIVE =0 ,CHANNEL_MGR_VM_ACTIVE };
@@ -66,6 +73,7 @@ struct channel_info {volatile uint32_t status;/**< Connection status(enum channel_status) */ int fd;/**< AF_UNIX socket fd */ unsigned channel_num;/**< CHANNEL_MGR_SOCKET_PATH/<vm_name>.channel_num */ +enum channel_type type;/**< Binary, ini, json, etc. */ void *priv_info;/**< Pointer to private info, do not modify */ };
@@ -226,6 +234,15 @@ int add_all_channels(const char *vm_name);int add_channels (const char *vm_name,unsigned *channel_list,unsigned num_channels); +/** +* Set up a fifo by which host applications can send command an policies +* through a fifo to the vm_power_manager +* +* @return +* - 0 for success +*/ +int add_host_channel (void ); +/** * Remove a channel definition from the channel manager. This must only be * called from the channel monitor thread.
examples/vm_power_manager/channel_monitor.c +108 -34
221 lines not on this page · raw message
examples/vm_power_manager/main.c +2 -0
@@ -421,6 +421,8 @@ main(int argc, char **argv)return -1 ; } +add_host_channel (); +printf ("Running core monitor on lcore id %d\n" , lcore_id);rte_eal_remote_launch (run_core_monitor,NULL , lcore_id);
Signature · 1 line
2.17.1
PATCH v5 6/10 examples/power: increase allowed number of clients
In reply to David HuntNow that we're handling host policies, containers and virtual machines, we'll rename MAX_VMS to MAX_CLIENTS, and increase from 4 to 64
--- examples/vm_power_manager/channel_manager.h | 4 ++-- examples/vm_power_manager/channel_monitor.c | 10 +++++----- 2 files changed, 7 insertions(+), 7 deletions(-)
examples/vm_power_manager/channel_manager.h +2 -2
@@ -37,7 +37,7 @@ struct sockaddr_un _sockaddr_un;#define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path)#endif -#define MAX_VMS 4 +#define MAX_CLIENTS 64#define MAX_VCPUS 20
@@ -47,7 +47,7 @@ struct libvirt_vm_info {uint8_t num_cpus; }; -struct libvirt_vm_info lvm_info[MAX_VMS ]; +struct libvirt_vm_info lvm_info[MAX_CLIENTS ];/* Communication Channel Status */ enum channel_status {CHANNEL_MGR_CHANNEL_DISCONNECTED =0 ,CHANNEL_MGR_CHANNEL_CONNECTED ,
examples/vm_power_manager/channel_monitor.c +5 -5
@@ -41,7 +41,7 @@ static volatile unsigned run_loop = 1;static int global_event_fd;static unsigned int policy_is_set;static struct epoll_event *global_events_list; -static struct policy policies[MAX_VMS ]; +static struct policy policies[MAX_CLIENTS ];void channel_monitor_exit (void ) {
@@ -199,7 +199,7 @@ update_policy(struct channel_packet *pkt)RTE_LOG (INFO ,CHANNEL_MONITOR ,"Applying policy for %s\n" , pkt->vm_name); -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) {/* Copy the contents of *pkt into the policy.pkt */ policies[i].pkt = *pkt;
@@ -214,7 +214,7 @@ update_policy(struct channel_packet *pkt) } }if (!updated) { -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (policies[i].enabled ==0 ) { policies[i].pkt = *pkt;get_pcpu_to_control (&policies[i]);
@@ -238,7 +238,7 @@ remove_policy(struct channel_packet *pkt __rte_unused)* Disabling the policy is simply a case of setting * enabled to 0 */ -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) { policies[i].enabled =0 ;return 0 ;
@@ -609,7 +609,7 @@ run_channel_monitor(void)if (policy_is_set) {int j; -for (j =0 ; j <MAX_VMS ; j++) { +for (j =0 ; j <MAX_CLIENTS ; j++) {if (policies[j].enabled ==1 )apply_policy (&policies[j]); }
Signature · 1 line
2.17.1
PATCH v5 7/10 examples/power: add json string handling
In reply to David HuntAdd JSON string handling to vm_power_manager for JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, the vm_power_manager user guide documentation updates.
This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
--- examples/vm_power_manager/Makefile | 6 + examples/vm_power_manager/channel_monitor.c | 269 ++++++++++++++++++-- 2 files changed, 250 insertions(+), 25 deletions(-)
examples/vm_power_manager/Makefile +6 -0
@@ -31,6 +31,12 @@ CFLAGS += $(WERROR_FLAGS) LDLIBS += -lvirt +JANSSON := $(shell pkg-config --exists jansson; echo $$?) +ifeq ($(JANSSON), 0) +LDLIBS += $(shell pkg-config --libs jansson) +CFLAGS += -DUSE_JANSSON +endif + ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
examples/vm_power_manager/channel_monitor.c +244 -25
304 lines not on this page · raw message
Signature · 1 line
2.17.1
Re: [PATCH v5 07/10] examples/power: add json string handling
Quoted 7 lines
examples/vm_power_manager/channel_monitor.c +7
-0+#ifdef USE_JANSSON +static int +parse_json_to_pkt (json_t *element,struct channel_packet *pkt) +{ +const char *key; +json_t *value; +int ret;
examples/vm_power_manager/channel_monitor.c static unsigned int policy_is_set; · line 71
Quoted 10 lines
examples/vm_power_manager/channel_monitor.c +10
-0+ +memset (pkt,0 ,sizeof (struct channel_packet )); + + pkt->nb_mac_to_monitor =0 ; + pkt->t_boost_status.tbEnabled = false; + pkt->workload =LOW ; + pkt->policy_to_use =TIME ; + pkt->command =PKT_POLICY ; + pkt->core_type =CORE_TYPE_PHYSICAL ; +
Hi, Dave
For the workload policy , it's set to LOW by default, but we can't change it again using JSON file channel. Is it by design?
Re: [PATCH v5 07/10] examples/power: add json string handling
Hi Lei,
Quoted 20 lines · Lei A
Quoted 7 lines
examples/vm_power_manager/channel_monitor.c +7
-0+#ifdef USE_JANSSON +static int +parse_json_to_pkt (json_t *element,struct channel_packet *pkt) +{ +const char *key; +json_t *value; +int ret;examples/vm_power_manager/channel_monitor.c static unsigned int policy_is_set; · line 71
Quoted 10 lines
examples/vm_power_manager/channel_monitor.c +10
-0+ +memset (pkt,0 ,sizeof (struct channel_packet )); + + pkt->nb_mac_to_monitor =0 ; + pkt->t_boost_status.tbEnabled = false; + pkt->workload =LOW ; + pkt->policy_to_use =TIME ; + pkt->command =PKT_POLICY ; + pkt->core_type =CORE_TYPE_PHYSICAL ; +Hi, Dave
Quoted 3 lines
For the workload policy , it's set to LOW by default, but we can't change it again using JSON file channel. Is it by design?
It was because the VMs currently only send binary structures. But they may send JSON data in the future so I should add it now. I'll upload a new version of the patch set today.
Thanks,
Dave.
PATCH v5 8/10 examples/power: clean up verbose messages
In reply to David HuntSome messages appearing several times a second, removing as they are unnecessary. Other less severe messages change from INFO to DEBUG
--- examples/vm_power_manager/channel_monitor.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-)
examples/vm_power_manager/channel_monitor.c +5 -14
@@ -259,7 +259,7 @@ get_pcpu_to_control(struct policy *pol) ci =get_core_info (); -RTE_LOG (INFO ,CHANNEL_MONITOR , +RTE_LOG (DEBUG ,CHANNEL_MONITOR ,"Looking for pcpu for %s\n" , pol->pkt.vm_name);/*
@@ -426,8 +426,6 @@ apply_traffic_profile(struct policy *pol) diff =get_pkt_diff (pol); -RTE_LOG (INFO ,CHANNEL_MONITOR ,"Applying traffic profile\n" ); -if (diff >= (pol->pkt.traffic_policy.max_max_packet_thresh)) {for (count =0 ; count < pol->pkt.num_vcpu; count++) {if (pol->core_share[count].status !=1 )
@@ -471,9 +469,6 @@ apply_time_profile(struct policy *pol)if (pol->core_share[count].status !=1 ) {power_manager_scale_core_max ( pol->core_share[count].pcpu); -RTE_LOG (INFO ,CHANNEL_MONITOR , -"Scaling up core %d to max\n" , - pol->core_share[count].pcpu); } }break ;
@@ -483,9 +478,6 @@ apply_time_profile(struct policy *pol)if (pol->core_share[count].status !=1 ) {power_manager_scale_core_min ( pol->core_share[count].pcpu); -RTE_LOG (INFO ,CHANNEL_MONITOR , -"Scaling down core %d to min\n" , - pol->core_share[count].pcpu); } }break ;
@@ -547,8 +539,6 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info)if (chan_info ==NULL )return -1 ; -RTE_LOG (INFO ,CHANNEL_MONITOR ,"Processing Request %s\n" , pkt->vm_name); -if (rte_atomic32_cmpset (&(chan_info->status),CHANNEL_MGR_CHANNEL_CONNECTED ,CHANNEL_MGR_CHANNEL_PROCESSING ) ==0 )return -1 ;
@@ -617,8 +607,8 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info) }if (pkt->command ==PKT_POLICY ) { -RTE_LOG (INFO ,CHANNEL_MONITOR , -"\nProcessing Policy request\n" ); +RTE_LOG (INFO ,CHANNEL_MONITOR ,"Processing policy request %s\n" , + pkt->vm_name);update_policy (pkt); policy_is_set =1 ; }
@@ -802,7 +792,8 @@ run_channel_monitor(void) global_events_list[i].data.ptr;if ((global_events_list[i].events &EPOLLERR ) || (global_events_list[i].events &EPOLLHUP )) { -RTE_LOG (DEBUG ,CHANNEL_MONITOR ,"Remote closed connection for " +RTE_LOG (INFO ,CHANNEL_MONITOR , +"Remote closed connection for " "channel '%s'\n" , chan_info->channel_path);remove_channel (&chan_info);
Signature · 1 line
2.17.1
PATCH v5 9/10 examples/power: add meson/ninja build support
In reply to David HuntAdd meson.build in vm_power_manager and the guest_cli subdirectory. Building can be achieved by going to the build directory, and using
meson configure -Dexamples=vm_power_manager,vm_power_manager/guest_cli
Then, when ninja is invoked, it will build dpdk-vm_power_manger and dpdk-guest_cli
Work still needs to be done on the meson build system to handles the case where the target list of example apps is defined as 'all'. That will come in a future patch.
--- .../vm_power_manager/guest_cli/meson.build | 21 +++++++++++ examples/vm_power_manager/meson.build | 37 ++++++++++++++++++- 2 files changed, 56 insertions(+), 2 deletions(-) create mode 100644 examples/vm_power_manager/guest_cli/meson.build
examples/vm_power_manager/guest_cli/meson.build new file +21 -0
@@ -0,0 +1,21 @@ +# SPDX-License-Identifier: BSD-3-Clause +# Copyright(c) 2018 Intel Corporation + +# meson file, for building this example as part of a main DPDK build. +# +# To build this example as a standalone application with an already-installed +# DPDK instance, use 'make' + +# Setting the name here because the default name will conflict with the +# vm_power_manager app because of the way the directories are parsed. +name = 'guest_cli' + +deps += ['power'] + +sources = files( + 'main.c', 'parse.c', 'vm_power_cli_guest.c' +) + +opt_dep = cc.find_library('virt', required : false) +build = opt_dep.found() +ext_deps += opt_dep
examples/vm_power_manager/meson.build +35 -2
@@ -6,5 +6,38 @@ # To build this example as a standalone application with an already-installed # DPDK instance, use 'make' -# Example app currently unsupported by meson build -build = false +if dpdk_conf.has('RTE_LIBRTE_BNXT_PMD') + deps += ['pmd_bnxt'] +endif + +if dpdk_conf.has('RTE_LIBRTE_I40E_PMD') + deps += ['pmd_i40e'] +endif + +if dpdk_conf.has('RTE_LIBRTE_IXGBE_PMD') + deps += ['pmd_ixgbe'] +endif + +deps += ['power'] + + +sources = files( + 'channel_manager.c', 'channel_monitor.c', 'main.c', 'parse.c', 'power_manager.c', 'vm_power_cli.c' +) + +# If we're on X86, pull in the x86 code for the branch monitor algo. +if dpdk_conf.has('RTE_ARCH_X86_64') + sources += files('oob_monitor_x86.c') +else + sources += files('oob_monitor_nop.c') +endif + +opt_dep = cc.find_library('virt', required : false) +build = opt_dep.found() +ext_deps += opt_dep + +opt_dep = dependency('jansson', required : false) +if opt_dep.found() + ext_deps += opt_dep + cflags += '-DUSE_JANSSON' +endif
Signature · 1 line
2.17.1
PATCH v5 10/10 doc/vm_power_manager: add JSON interface API info
In reply to David HuntAlso added meson/ninja build info
--- .../sample_app_ug/vm_power_management.rst | 272 +++++++++++++++++- 1 file changed, 270 insertions(+), 2 deletions(-)
doc/guides/sample_app_ug/vm_power_management.rst +270 -2
@@ -199,7 +199,7 @@ see :doc:`compiling`. The application is located in the ``vm_power_manager`` sub-directory. -To build just the ``vm_power_manager`` application: +To build just the ``vm_power_manager`` application using ``make``: .. code-block:: console
@@ -208,6 +208,22 @@ To build just the ``vm_power_manager`` application: cd ${RTE_SDK}/examples/vm_power_manager/ make +The resulting binary will be ${RTE_SDK}/build/examples/vm_power_manager + +To build just the ``vm_power_manager`` application using ``meson/ninja``: + +.. code-block:: console + + export RTE_SDK=/path/to/rte_sdk + cd ${RTE_SDK} + meson build + cd build + ninja + meson configure -Dexamples=vm_power_manager + ninja + +The resulting binary will be ${RTE_SDK}/build/examples/dpdk-vm_power_manager + Running ~~~~~~~
@@ -337,6 +353,242 @@ monitoring of branch ratio on cores doing busy polling via PMDs. and will need to be adjusted for different workloads. + +JSON API +~~~~~~~~ + +In addition to the command line interface for host command and a virtio-serial +interface for VM power policies, there is also a JSON interface through which +power commands and policies can be sent. This functionality adds a dependency +on the Jansson library, and the Jansson development package must be installed +on the system before the JSON parsing functionality is included in the app. +This is achieved by: + + .. code-block:: javascript + + apt-get install libjansson-dev + +The command and package name may be different depending on your operating +system. It's worth noting that the app will successfully build without this +package present, but a warning is shown during compilation, and the JSON +parsing functionality will not be present in the app. + +Sending a command or policy to the power manager application is achieved by +simply opening a fifo file, writing a JSON string to that fifo, and closing +the file. + +The fifo is at /tmp/powermonitor/fifo + +The jason string can be a policy or instruction, and takes the following +format: + + .. code-block:: javascript + + {"packet_type": { + "pair_1": value, + "pair_2": value + }} + +The 'packet_type' header can contain one of two values, depending on +whether a policy or power command is being sent. The two possible values are +"policy" and "instruction", and the expected name-value pairs is different +depending on which type is being sent. + +The pairs are the format of standard JSON name-value pairs. The value type +varies between the different name/value pairs, and may be integers, strings, +arrays, etc. Examples of policies follow later in this document. The allowed +names and value types are as follows: + + +:Pair Name: "name" +:Description: Name of the VM or Host. Allows the parser to associate the + policy with the relevant VM or Host OS. +:Type: string +:Values: any valid string +:Required: yes +:Example: + + .. code-block:: javascript + + "name", "ubuntu2" + + +:Pair Name: "command" +:Description: The type of packet we're sending to the power manager. We can be + creating or destroying a policy, or sending a direct command to adjust + the frequency of a core, similar to the command line interface. +:Type: string +:Values: + + :CREATE: used when creating a new policy, + :DESTROY: used when removing a policy, + :POWER: used when sending an immediate command, max, min, etc. +:Required: yes +:Example: + + .. code-block:: javascript + + "command", "CREATE" + + +:Pair Name: "policy_type" +:Description: Type of policy to apply. Please see vm_power_manager documentation + for more information on the types of policies that may be used. +:Type: string +:Values: + + :TIME: Time-of-day policy. Frequencies of the relevant cores are + scaled up/down depending on busy and quiet hours. + :TRAFFIC: This policy takes statistics from the NIC and scales up + and down accordingly. + :WORKLOAD: This policy looks at how heavily loaded the cores are, + and scales up and down accordingly. + :BRANCH_RATIO: This out-of-band policy can look at the ratio between + branch hits and misses on a core, and is useful for detecting + how much packet processing a core is doing. +:Required: only for CREATE/DESTROY command +:Example: + + .. code-block:: javascript + + "policy_type", "TIME" + +:Pair Name: "busy_hours" +:Description: The hours of the day in which we scale up the cores for busy + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: javascript + + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ] + +:Pair Name: "quiet_hours" +:Description: The hours of the day in which we scale down the cores for quiet + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: javascript + + "quiet_hours":[ 2, 3, 4, 5, 6 ] + +:Pair Name: "avg_packet_thresh" +:Description: Threshold below which the frequency will be set to min for + the TRAFFIC policy. If the traffic rate is above this and below max, the + frequency will be set to medium. +:Type: integer +:Values: The number of packets below which the TRAFFIC policy applies the + minimum frequency, or medium frequency if between avg and max thresholds. +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: javascript + + "avg_packet_thresh": 100000 + +:Pair Name: "max_packet_thresh" +:Description: Threshold above which the frequency will be set to max for + the TRAFFIC policy +:Type: integer +:Values: The number of packets per interval above which the TRAFFIC policy + applies the maximum frequency +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: javascript + + "max_packet_thresh": 500000 + +:Pair Name: "core_list" +:Description: The cores to which to apply the policy. +:Type: array of integers +:Values: array with list of virtual CPUs. +:Required: only policy CREATE/DESTROY +:Example: + + .. code-block:: javascript + + "core_list":[ 10, 11 ] + +:Pair Name: "unit" +:Description: the type of power operation to apply in the command +:Type: string +:Values: + + :SCALE_MAX: Scale frequency of this core to maximum + :SCALE_MIN: Scale frequency of this core to minimum + :SCALE_UP: Scale up frequency of this core + :SCALE_DOWN: Scale down frequency of this core + :ENABLE_TURBO: Enable Turbo Boost for this core + :DISABLE_TURBO: Disable Turbo Boost for this core +:Required: only for POWER instruction +:Example: + + .. code-block:: javascript + + "unit", "SCALE_MAX" + +:Pair Name: "resource_id" +:Description: The core to which to apply the power command. +:Type: integer +:Values: valid core id for VM or host OS. +:Required: only POWER instruction +:Example: + + .. code-block:: javascript + + "resource_id": 10 + +JSON API Examples +~~~~~~~~~~~~~~~~~ + +Profile create example: + + .. code-block:: javascript + + {"policy": { + "name": "ubuntu", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11 ] + }} + +Profile destroy example: + + .. code-block:: javascript + + {"profile": { + "name": "ubuntu", + "command": "destroy", + }} + +Power command example: + + .. code-block:: javascript + + {"command": { + "name": "ubuntu", + "unit": "SCALE_MAX", + "resource_id": 10 + }} + +To send a JSON string to the Power Manager application, simply paste the +example JSON string into a text file and cat it into the fifo: + + .. code-block:: console + + cat file.json >/tmp/powermonitor/fifo + +The console of the Power Manager application should indicate the command that +was just received via the fifo. + Compiling and Running the Guest Applications --------------------------------------------
@@ -366,7 +618,7 @@ For compiling and running l3fwd-power, see :doc:`l3_forward_power_man`. The application is located in the ``guest_cli`` sub-directory under ``vm_power_manager``. -To build just the ``guest_vm_power_manager`` application: +To build just the ``guest_vm_power_manager`` application using ``make``: .. code-block:: console
@@ -375,6 +627,22 @@ To build just the ``guest_vm_power_manager`` application: cd ${RTE_SDK}/examples/vm_power_manager/guest_cli/ make +The resulting binary will be ${RTE_SDK}/build/examples/guest_cli + +To build just the ``vm_power_manager`` application using ``meson/ninja``: + +.. code-block:: console + + export RTE_SDK=/path/to/rte_sdk + cd ${RTE_SDK} + meson build + cd build + ninja + meson configure -Dexamples=vm_power_manager/guest_cli + ninja + +The resulting binary will be ${RTE_SDK}/build/examples/guest_cli + Running ~~~~~~~
Signature · 1 line
2.17.1
Re: [PATCH v5 10/10] doc/vm_power_manager: add JSON interface API info
Quoted 10 lines
+:Pair Name: "
avg_packet_thresh"
+:Description: Threshold below which the frequency will be set to min fordoc/guides/sample_app_ug/vm_power_management.rst +5
-0+ the TRAFFIC policy. If the traffic rate is above this and below max, the + frequency will be set to medium. +:Type: integer +:Values: The number of packets below which the TRAFFIC policy applies the + minimum frequency, or medium frequency if between avg and maxthresholds.
+:Required: only for TRAFFIC policy
+:Example:
doc/guides/sample_app_ug/vm_power_management.rst monitoring of branch ratio on cores doing busy polling via PMDs. · line 492
Quoted 4 lines
doc/guides/sample_app_ug/vm_power_management.rst +4
-0+ + .. code-block:: javascript + + "avg_packet_thresh": 100000
Hi, Dave
For this traffic policy , seems in previous release, we depends on the application in VM to send the VF mac address info back to the host vm_power_manager sample in host through virtio-serial port. If this JOSN interface is designed for container using VF, do we need add VF mac or ID related info into the TRAFFIC policy JSON file? Otherwise, the host don't know which port to monitor the throughput, I guess.
Re: [PATCH v5 10/10] doc/vm_power_manager: add JSON interface API info
Hi Lei,
Quoted 16 lines · Lei A
Quoted 10 lines
+:Pair Name: "
avg_packet_thresh"
+:Description: Threshold below which the frequency will be set to min fordoc/guides/sample_app_ug/vm_power_management.rst +5
-0+ the TRAFFIC policy. If the traffic rate is above this and below max, the + frequency will be set to medium. +:Type: integer +:Values: The number of packets below which the TRAFFIC policy applies the + minimum frequency, or medium frequency if between avg and maxthresholds.
+:Required: only for TRAFFIC policy
+:Example:doc/guides/sample_app_ug/vm_power_management.rst monitoring of branch ratio on cores doing busy polling via PMDs. · line 492
Quoted 4 lines
doc/guides/sample_app_ug/vm_power_management.rst +4
-0+ + .. code-block:: javascript + + "avg_packet_thresh": 100000Hi, Dave
Quoted 8 lines
For this traffic policy , seems in previous release, we depends on the application in VM to send the VF mac address info back to the host
vm_power_managersample in host through virtio-serial port. If this JOSN interface is designed for container using VF, do we need add VF mac or ID related info into the TRAFFIC policy JSON file? Otherwise, the host don't know which port to monitor the throughput, I guess.
Well spotted. I'll add this and upload a new version.
Thanks,
Dave.
v6 cover add json power policy interface for containers
In reply to David HuntThe current vm_power_manager example app has the capability to accept power policies from virtual machines via virtio-serial channels. These power policies allow a virtual machine to give information to the power manager to allow the power manager take care of the power management of the virtual machine based on the information in the policy.
This power policy functionality is limited to virtual machines sending the policies to the power manager (which runs in the Host OS), and a solution was needed for additional methods of sending power policies to the power manager app.
The main use-case for this modification is for containers and host applications that wish to send polices to the power manager.
This patchset adds the capability to send power polices and power commands to the vm_power_manager app via JSON strings through a fifo on the file system.
For example, given the following file, policy.json:
{"policy": {
"name": "ubuntu2",
"command": "create",
"policy_type": "TIME",
"busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ],
"quiet_hours":[ 2, 3, 4, 5, 6 ],
"core_list":[ 11, 12, 13 ]
}}
Then running the command:
cat policy.json >/tmp/powermonitor/fifo
The policy is sent to the vm_power_manager. The power manager app then parses the JSON data, and inserts the policy into the array of policies.
Part of the patch series contains documentation updates to give all the details of the valid name-value pairs, the data types, etc.
Patch v2:
* Fixed review comments from Stephen Hemminger and Lei A Yao.
* Added a check in the Makefile for libjansson-dev. Will Warn user and build without JSON functionality if not present, will build including JSON functionality if it is present.
Patch v3:
* Added meson/ninja support for vm_power_manager and guest_cli apps
* Fixed compilation issue with guest_cli app
Patch v4:
* Split out some unrelated changes to separate patches in the set
* Some changes out of review by Anatoly (Thanks!)
Patch v5:
* Removed the directory with JSON examples, as they already exist in the documentation.
* Fixed some typos and formatting issues in the documentation.
* Changed the JSON examples in the documentation to 'javascript' causing the syntax to be highlighted nicely.
* Inherited the Acks from previous version.
Patch v6:
* Added ability to set WORKLOAD policy to LOW, MEDIUM, or HIGH. "workload": "MEDIUM"
* Added missing functionality to allow passing of a list of mac addresses for the TRAFFIC profile type. "mac_list":[ "de:ad:be:ef:01:01", "de:ad:be:ef:01:02" ]
* Updated docs to include both of the above additions.
[01/10] examples/power: add checks around hypervisor [02/10] examples/power: allow for number of vms to be zero [03/10] lib/power: add changes for host commands/policies [04/10] examples/power: add necessary changes to guest app [05/10] examples/power: add host channel to power manager [06/10] examples/power: increase allowed number of clients [07/10] examples/power: add json string handling [08/10] examples/power: clean up verbose messages [09/10] examples/power: add meson/ninja build support [10/10] doc/vm_power_manager: add JSON interface API info
PATCH v6 1/10 examples/power: add checks around hypervisor
Allow vm_power_manager to run without requiring qemu to be present on the machine. This will be required for instances where the JSON interface is used for commands and polices, without any VMs present. A use case for this is a container enviromnent.
--- examples/vm_power_manager/channel_manager.c | 71 +++++++++++++-------- 1 file changed, 43 insertions(+), 28 deletions(-)
examples/vm_power_manager/channel_manager.c +43 -28
@@ -43,7 +43,8 @@ static unsigned char *global_cpumaps;static virVcpuInfo *global_vircpuinfo;static size_t global_maplen; -static unsigned global_n_host_cpus; +static unsigned int global_n_host_cpus; +static bool global_hypervisor_available;/* * Represents a single Virtual Machine
@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) {struct virtual_machine_info *vm_info = (struct virtual_machine_info *)chan_info->priv_info; -return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); + +if (global_hypervisor_available && (vm_info !=NULL )) +return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); +else +return 0 ; } static inline int
@@ -559,6 +564,8 @@ get_all_vm(int *num_vm, int *num_vcpu)VIR_CONNECT_LIST_DOMAINS_PERSISTENT ;unsigned int domain_flag =VIR_DOMAIN_VCPU_CONFIG ; +if (!global_hypervisor_available) +return ;memset (global_cpumaps,0 ,CHANNEL_CMDS_MAX_CPUS *global_maplen);if (virNodeGetInfo (global_vir_conn_ptr, &node_info)) {
@@ -768,38 +775,42 @@ connect_hypervisor(const char *path) }return 0 ; } -int -channel_manager_init (const char *path) +channel_manager_init(const char *path __rte_unused) {virNodeInfo info;LIST_INIT (&vm_list_head);if (connect_hypervisor (path) <0 ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); -return -1 ; - } - - global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + global_n_host_cpus =64 ; + global_hypervisor_available =0 ; +RTE_LOG (INFO ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); + }else { + global_hypervisor_available =1 ; + + global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + + global_vircpuinfo =rte_zmalloc (NULL , +sizeof (*global_vircpuinfo) * +CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); +if (global_vircpuinfo ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); + goto error; + } + global_cpumaps =rte_zmalloc (NULL , +CHANNEL_CMDS_MAX_CPUS * global_maplen, +RTE_CACHE_LINE_SIZE ); +if (global_cpumaps ==NULL ) + goto error; - global_vircpuinfo =rte_zmalloc (NULL ,sizeof (*global_vircpuinfo) * -CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); -if (global_vircpuinfo ==NULL ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); - goto error; - } - global_cpumaps =rte_zmalloc (NULL ,CHANNEL_CMDS_MAX_CPUS * global_maplen, -RTE_CACHE_LINE_SIZE ); -if (global_cpumaps ==NULL ) { - goto error; +if (virNodeGetInfo (global_vir_conn_ptr, &info)) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); + goto error; + } + global_n_host_cpus = (unsigned int )info.cpus; } -if (virNodeGetInfo (global_vir_conn_ptr, &info)) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); - goto error; - } - global_n_host_cpus = (unsigned )info.cpus;if (global_n_host_cpus >CHANNEL_CMDS_MAX_CPUS ) { RTE_LOG(WARNING, CHANNEL_MANAGER, "The number of host CPUs(%u) exceeds the "
@@ -811,7 +822,8 @@ channel_manager_init(const char *path)return 0 ; error: -disconnect_hypervisor (); +if (global_hypervisor_available) +disconnect_hypervisor ();return -1 ; }
@@ -838,7 +850,10 @@ channel_manager_exit(void)rte_free (vm_info); } -rte_free (global_cpumaps); -rte_free (global_vircpuinfo); -disconnect_hypervisor (); +if (global_hypervisor_available) { +/* Only needed if hypervisor available */ +rte_free (global_cpumaps); +rte_free (global_vircpuinfo); +disconnect_hypervisor (); + } }
Signature · 1 line
2.17.1
PATCH v6 2/10 examples/power: allow for number of vms to be zero
In reply to David HuntPreviously the vm_power_manager app required to have some vms defined, so the call to get_all_vm() always set the noVms variable. Now we're accepting policies from the host OS (without any VMs defined), so it is now valid to have zero VMs. This patch initialises the relevant variables to zero just in case the call to get_all_vms() does not find any, so could return with the variables uninitialised.
--- examples/vm_power_manager/channel_monitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
examples/vm_power_manager/channel_monitor.c +1 -1
@@ -66,7 +66,7 @@ static void core_share_status(int pNo) { -int noVms, noVcpus, z, x, t; +int noVms =0 , noVcpus =0 , z, x, t;get_all_vm (&noVms, &noVcpus);
Signature · 1 line
2.17.1
PATCH v6 3/10 lib/power: add changes for host commands/policies
In reply to David HuntThis patch does a couple of things:
* Adds a new message type for removing policies (PKT_POLICY_REMOVE) Used when we want to remove a previously created policy.
* Adds a core_type bool to the channel packet struct to specify whether the type of core we want to control is cirtual or physical.
--- lib/librte_power/channel_commands.h | 5 +++++ 1 file changed, 5 insertions(+)
lib/librte_power/channel_commands.h +5 -0
@@ -19,6 +19,7 @@ extern "C" {#define CPU_POWER 1#define CPU_POWER_CONNECT 2#define PKT_POLICY 3 +#define PKT_POLICY_REMOVE 4/* CPU Power Command Scaling */ #define CPU_POWER_SCALE_UP 1
@@ -58,6 +59,9 @@ struct traffic {uint32_t max_max_packet_thresh; }; +#define CORE_TYPE_VIRTUAL 0 +#define CORE_TYPE_PHYSICAL 1 +struct channel_packet {uint64_t resource_id;/**< core_num, device */ uint32_t unit;/**< scale down/up/min/max */
@@ -70,6 +74,7 @@ struct channel_packet {uint8_t vcpu_to_control[MAX_VCPU_PER_VM ];uint8_t num_vcpu;struct timer_profile timer_policy; +bool core_type;enum workload workload;enum policy_to_use policy_to_use;struct t_boost_status t_boost_status;
Signature · 1 line
2.17.1
PATCH v6 4/10 examples/power: add necessary changes to guest app
In reply to David HuntThe changes here are minimal, as the guest app functionality is not changing at all, but there is a new element in the channel_packet struct that needs to have a default set (channel_packet->core_type).
--- examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 1 + 1 file changed, 1 insertion(+)
examples/vm_power_manager/guest_cli/vm_power_cli_guest.c +1 -0
@@ -92,6 +92,7 @@ set_policy_defaults(struct channel_packet *pkt) pkt->timer_policy.hours_to_use_traffic_profile[0 ] =8 ; pkt->timer_policy.hours_to_use_traffic_profile[1 ] =10 ; + pkt->core_type =CORE_TYPE_VIRTUAL ; pkt->workload =LOW ; pkt->policy_to_use =TIME ; pkt->command =PKT_POLICY ;
Signature · 1 line
2.17.1
PATCH v6 5/10 examples/power: add host channel to power manager
In reply to David HuntThis patch adds a fifo channel to the vm_power_manager app through which we can send commands and polices. Intended for sending JSON strings. The fifo is at /tmp/powermonitor/fifo
--- examples/vm_power_manager/channel_manager.c | 109 +++++++++++++++ examples/vm_power_manager/channel_manager.h | 17 +++ examples/vm_power_manager/channel_monitor.c | 142 +++++++++++++++----- examples/vm_power_manager/main.c | 2 + 4 files changed, 236 insertions(+), 34 deletions(-)
examples/vm_power_manager/channel_manager.c +109 -0
@@ -13,6 +13,7 @@#include <sys/queue.h> #include <sys/types.h> +#include <sys/stat.h> #include <sys/socket.h> #include <sys/select.h>
@@ -284,6 +285,38 @@ open_non_blocking_channel(struct channel_info *info)return 0 ; } +static int +open_host_channel (struct channel_info *info) +{ +int flags; + + info->fd =open (info->channel_path,O_RDWR |O_RSYNC ); +if (info->fd ==-1 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error(%s) opening fifo for '%s'\n" , +strerror (errno), + info->channel_path); +return -1 ; + } + +/* Get current flags */ + flags =fcntl (info->fd,F_GETFL ,0 ); +if (flags <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER ,"Error(%s) fcntl get flags socket for" +"'%s'\n" ,strerror (errno), info->channel_path); +return 1 ; + } +/* Set to Non Blocking */ + flags |=O_NONBLOCK ; +if (fcntl (info->fd,F_SETFL , flags) <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER , +"Error(%s) setting non-blocking " +"socket for '%s'\n" , +strerror (errno), info->channel_path); +return -1 ; + } +return 0 ; +} +static int setup_channel_info (struct virtual_machine_info **vm_info_dptr,struct channel_info **chan_info_dptr,unsigned channel_num)
@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, chan_info->channel_num = channel_num; chan_info->priv_info = (void *)vm_info; chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_BINARY ;if (open_non_blocking_channel (chan_info) <0 ) { RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open channel: " "'%s' for VM '%s'\n",
@@ -316,6 +350,42 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr,return 0 ; } +static void +fifo_path (char *dst,unsigned int len) +{ +snprintf (dst, len,"%sfifo" ,CHANNEL_MGR_SOCKET_PATH ); +} + +static int +setup_host_channel_info (struct channel_info **chan_info_dptr, +unsigned int channel_num) +{ +struct channel_info *chan_info = *chan_info_dptr; + + chan_info->channel_num = channel_num; + chan_info->priv_info = (void *)NULL ; + chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_JSON ; + +fifo_path (chan_info->channel_path,sizeof (chan_info->channel_path)); + +if (open_host_channel (chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could not open host channel: " +"'%s'\n" , + chan_info->channel_path); +return -1 ; + } +if (add_channel_to_monitor (&chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could add channel: " +"'%s' to epoll ctl\n" , + chan_info->channel_path); +return -1 ; + + } + chan_info->status =CHANNEL_MGR_CHANNEL_CONNECTED ; +return 0 ; +} +int add_all_channels (const char *vm_name) {
@@ -470,6 +540,45 @@ add_channels(const char *vm_name, unsigned *channel_list,return num_channels_enabled; } +int +add_host_channel (void ) +{ +struct channel_info *chan_info; +char socket_path[PATH_MAX ]; +int num_channels_enabled =0 ; +int ret; + +fifo_path (socket_path,sizeof (socket_path)); + + ret =mkfifo (socket_path,0660 ); +if ((errno !=EEXIST ) && (ret <0 )) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Cannot create fifo '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + +if (access (socket_path,F_OK ) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Channel path '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + chan_info =rte_malloc (NULL ,sizeof (*chan_info),0 ); +if (chan_info ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for " +"channel '%s'\n" , socket_path); +return 0 ; + } +snprintf (chan_info->channel_path, +sizeof (chan_info->channel_path),"%s" , socket_path); +if (setup_host_channel_info (&chan_info,0 ) <0 ) { +rte_free (chan_info); +return 0 ; + } + num_channels_enabled++; + +return num_channels_enabled; +} +int remove_channel (struct channel_info **chan_info_dptr) {
examples/vm_power_manager/channel_manager.h +17 -0
@@ -54,6 +54,13 @@ enum channel_status { CHANNEL_MGR_CHANNEL_DISCONNECTED = 0,CHANNEL_MGR_CHANNEL_DISABLED , CHANNEL_MGR_CHANNEL_PROCESSING}; +/* Communication Channel Type */ +enum channel_type { +CHANNEL_TYPE_BINARY =0 , +CHANNEL_TYPE_INI , +CHANNEL_TYPE_JSON +}; +/* VM libvirt(qemu/KVM) connection status */ enum vm_status {CHANNEL_MGR_VM_INACTIVE =0 ,CHANNEL_MGR_VM_ACTIVE };
@@ -66,6 +73,7 @@ struct channel_info {volatile uint32_t status;/**< Connection status(enum channel_status) */ int fd;/**< AF_UNIX socket fd */ unsigned channel_num;/**< CHANNEL_MGR_SOCKET_PATH/<vm_name>.channel_num */ +enum channel_type type;/**< Binary, ini, json, etc. */ void *priv_info;/**< Pointer to private info, do not modify */ };
@@ -226,6 +234,15 @@ int add_all_channels(const char *vm_name);int add_channels (const char *vm_name,unsigned *channel_list,unsigned num_channels); +/** +* Set up a fifo by which host applications can send command an policies +* through a fifo to the vm_power_manager +* +* @return +* - 0 for success +*/ +int add_host_channel (void ); +/** * Remove a channel definition from the channel manager. This must only be * called from the channel monitor thread.
examples/vm_power_manager/channel_monitor.c +108 -34
221 lines not on this page · raw message
examples/vm_power_manager/main.c +2 -0
@@ -421,6 +421,8 @@ main(int argc, char **argv)return -1 ; } +add_host_channel (); +printf ("Running core monitor on lcore id %d\n" , lcore_id);rte_eal_remote_launch (run_core_monitor,NULL , lcore_id);
Signature · 1 line
2.17.1
PATCH v6 6/10 examples/power: increase allowed number of clients
In reply to David HuntNow that we're handling host policies, containers and virtual machines, we'll rename MAX_VMS to MAX_CLIENTS, and increase from 4 to 64
--- examples/vm_power_manager/channel_manager.h | 4 ++-- examples/vm_power_manager/channel_monitor.c | 10 +++++----- 2 files changed, 7 insertions(+), 7 deletions(-)
examples/vm_power_manager/channel_manager.h +2 -2
@@ -37,7 +37,7 @@ struct sockaddr_un _sockaddr_un;#define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path)#endif -#define MAX_VMS 4 +#define MAX_CLIENTS 64#define MAX_VCPUS 20
@@ -47,7 +47,7 @@ struct libvirt_vm_info {uint8_t num_cpus; }; -struct libvirt_vm_info lvm_info[MAX_VMS ]; +struct libvirt_vm_info lvm_info[MAX_CLIENTS ];/* Communication Channel Status */ enum channel_status {CHANNEL_MGR_CHANNEL_DISCONNECTED =0 ,CHANNEL_MGR_CHANNEL_CONNECTED ,
examples/vm_power_manager/channel_monitor.c +5 -5
@@ -41,7 +41,7 @@ static volatile unsigned run_loop = 1;static int global_event_fd;static unsigned int policy_is_set;static struct epoll_event *global_events_list; -static struct policy policies[MAX_VMS ]; +static struct policy policies[MAX_CLIENTS ];void channel_monitor_exit (void ) {
@@ -199,7 +199,7 @@ update_policy(struct channel_packet *pkt)RTE_LOG (INFO ,CHANNEL_MONITOR ,"Applying policy for %s\n" , pkt->vm_name); -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) {/* Copy the contents of *pkt into the policy.pkt */ policies[i].pkt = *pkt;
@@ -214,7 +214,7 @@ update_policy(struct channel_packet *pkt) } }if (!updated) { -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (policies[i].enabled ==0 ) { policies[i].pkt = *pkt;get_pcpu_to_control (&policies[i]);
@@ -238,7 +238,7 @@ remove_policy(struct channel_packet *pkt __rte_unused)* Disabling the policy is simply a case of setting * enabled to 0 */ -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) { policies[i].enabled =0 ;return 0 ;
@@ -609,7 +609,7 @@ run_channel_monitor(void)if (policy_is_set) {int j; -for (j =0 ; j <MAX_VMS ; j++) { +for (j =0 ; j <MAX_CLIENTS ; j++) {if (policies[j].enabled ==1 )apply_policy (&policies[j]); }
Signature · 1 line
2.17.1
PATCH v6 7/10 examples/power: add json string handling
In reply to David HuntAdd JSON string handling to vm_power_manager for JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, the vm_power_manager user guide documentation updates.
This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
--- examples/vm_power_manager/Makefile | 6 + examples/vm_power_manager/channel_monitor.c | 371 ++++++++++++++++++-- 2 files changed, 352 insertions(+), 25 deletions(-)
examples/vm_power_manager/Makefile +6 -0
@@ -31,6 +31,12 @@ CFLAGS += $(WERROR_FLAGS) LDLIBS += -lvirt +JANSSON := $(shell pkg-config --exists jansson; echo $$?) +ifeq ($(JANSSON), 0) +LDLIBS += $(shell pkg-config --libs jansson) +CFLAGS += -DUSE_JANSSON +endif + ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
examples/vm_power_manager/channel_monitor.c +346 -25
406 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v6 8/10 examples/power: clean up verbose messages
In reply to David HuntSome messages appearing several times a second, removing as they are unnecessary. Other less severe messages change from INFO to DEBUG
--- examples/vm_power_manager/channel_monitor.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-)
examples/vm_power_manager/channel_monitor.c +5 -14
@@ -361,7 +361,7 @@ get_pcpu_to_control(struct policy *pol) ci =get_core_info (); -RTE_LOG (INFO ,CHANNEL_MONITOR , +RTE_LOG (DEBUG ,CHANNEL_MONITOR ,"Looking for pcpu for %s\n" , pol->pkt.vm_name);/*
@@ -528,8 +528,6 @@ apply_traffic_profile(struct policy *pol) diff =get_pkt_diff (pol); -RTE_LOG (INFO ,CHANNEL_MONITOR ,"Applying traffic profile\n" ); -if (diff >= (pol->pkt.traffic_policy.max_max_packet_thresh)) {for (count =0 ; count < pol->pkt.num_vcpu; count++) {if (pol->core_share[count].status !=1 )
@@ -573,9 +571,6 @@ apply_time_profile(struct policy *pol)if (pol->core_share[count].status !=1 ) {power_manager_scale_core_max ( pol->core_share[count].pcpu); -RTE_LOG (INFO ,CHANNEL_MONITOR , -"Scaling up core %d to max\n" , - pol->core_share[count].pcpu); } }break ;
@@ -585,9 +580,6 @@ apply_time_profile(struct policy *pol)if (pol->core_share[count].status !=1 ) {power_manager_scale_core_min ( pol->core_share[count].pcpu); -RTE_LOG (INFO ,CHANNEL_MONITOR , -"Scaling down core %d to min\n" , - pol->core_share[count].pcpu); } }break ;
@@ -649,8 +641,6 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info)if (chan_info ==NULL )return -1 ; -RTE_LOG (INFO ,CHANNEL_MONITOR ,"Processing Request %s\n" , pkt->vm_name); -if (rte_atomic32_cmpset (&(chan_info->status),CHANNEL_MGR_CHANNEL_CONNECTED ,CHANNEL_MGR_CHANNEL_PROCESSING ) ==0 )return -1 ;
@@ -719,8 +709,8 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info) }if (pkt->command ==PKT_POLICY ) { -RTE_LOG (INFO ,CHANNEL_MONITOR , -"\nProcessing Policy request\n" ); +RTE_LOG (INFO ,CHANNEL_MONITOR ,"Processing policy request %s\n" , + pkt->vm_name);update_policy (pkt); policy_is_set =1 ; }
@@ -904,7 +894,8 @@ run_channel_monitor(void) global_events_list[i].data.ptr;if ((global_events_list[i].events &EPOLLERR ) || (global_events_list[i].events &EPOLLHUP )) { -RTE_LOG (DEBUG ,CHANNEL_MONITOR ,"Remote closed connection for " +RTE_LOG (INFO ,CHANNEL_MONITOR , +"Remote closed connection for " "channel '%s'\n" , chan_info->channel_path);remove_channel (&chan_info);
Signature · 1 line
2.17.1
PATCH v6 9/10 examples/power: add meson/ninja build support
In reply to David HuntAdd meson.build in vm_power_manager and the guest_cli subdirectory. Building can be achieved by going to the build directory, and using
meson configure -Dexamples=vm_power_manager,vm_power_manager/guest_cli
Then, when ninja is invoked, it will build dpdk-vm_power_manger and dpdk-guest_cli
Work still needs to be done on the meson build system to handles the case where the target list of example apps is defined as 'all'. That will come in a future patch.
--- .../vm_power_manager/guest_cli/meson.build | 21 +++++++++++ examples/vm_power_manager/meson.build | 37 ++++++++++++++++++- 2 files changed, 56 insertions(+), 2 deletions(-) create mode 100644 examples/vm_power_manager/guest_cli/meson.build
examples/vm_power_manager/guest_cli/meson.build new file +21 -0
@@ -0,0 +1,21 @@ +# SPDX-License-Identifier: BSD-3-Clause +# Copyright(c) 2018 Intel Corporation + +# meson file, for building this example as part of a main DPDK build. +# +# To build this example as a standalone application with an already-installed +# DPDK instance, use 'make' + +# Setting the name here because the default name will conflict with the +# vm_power_manager app because of the way the directories are parsed. +name = 'guest_cli' + +deps += ['power'] + +sources = files( + 'main.c', 'parse.c', 'vm_power_cli_guest.c' +) + +opt_dep = cc.find_library('virt', required : false) +build = opt_dep.found() +ext_deps += opt_dep
examples/vm_power_manager/meson.build +35 -2
@@ -6,5 +6,38 @@ # To build this example as a standalone application with an already-installed # DPDK instance, use 'make' -# Example app currently unsupported by meson build -build = false +if dpdk_conf.has('RTE_LIBRTE_BNXT_PMD') + deps += ['pmd_bnxt'] +endif + +if dpdk_conf.has('RTE_LIBRTE_I40E_PMD') + deps += ['pmd_i40e'] +endif + +if dpdk_conf.has('RTE_LIBRTE_IXGBE_PMD') + deps += ['pmd_ixgbe'] +endif + +deps += ['power'] + + +sources = files( + 'channel_manager.c', 'channel_monitor.c', 'main.c', 'parse.c', 'power_manager.c', 'vm_power_cli.c' +) + +# If we're on X86, pull in the x86 code for the branch monitor algo. +if dpdk_conf.has('RTE_ARCH_X86_64') + sources += files('oob_monitor_x86.c') +else + sources += files('oob_monitor_nop.c') +endif + +opt_dep = cc.find_library('virt', required : false) +build = opt_dep.found() +ext_deps += opt_dep + +opt_dep = dependency('jansson', required : false) +if opt_dep.found() + ext_deps += opt_dep + cflags += '-DUSE_JANSSON' +endif
Signature · 1 line
2.17.1
PATCH v6 10/10 doc/vm_power_manager: add JSON interface API info
In reply to David HuntAlso added meson/ninja build info
--- .../sample_app_ug/vm_power_management.rst | 300 +++++++++++++++++- 1 file changed, 298 insertions(+), 2 deletions(-)
doc/guides/sample_app_ug/vm_power_management.rst +298 -2
@@ -199,7 +199,7 @@ see :doc:`compiling`. The application is located in the ``vm_power_manager`` sub-directory. -To build just the ``vm_power_manager`` application: +To build just the ``vm_power_manager`` application using ``make``: .. code-block:: console
@@ -208,6 +208,22 @@ To build just the ``vm_power_manager`` application: cd ${RTE_SDK}/examples/vm_power_manager/ make +The resulting binary will be ${RTE_SDK}/build/examples/vm_power_manager + +To build just the ``vm_power_manager`` application using ``meson/ninja``: + +.. code-block:: console + + export RTE_SDK=/path/to/rte_sdk + cd ${RTE_SDK} + meson build + cd build + ninja + meson configure -Dexamples=vm_power_manager + ninja + +The resulting binary will be ${RTE_SDK}/build/examples/dpdk-vm_power_manager + Running ~~~~~~~
@@ -337,6 +353,270 @@ monitoring of branch ratio on cores doing busy polling via PMDs. and will need to be adjusted for different workloads. + +JSON API +~~~~~~~~ + +In addition to the command line interface for host command and a virtio-serial +interface for VM power policies, there is also a JSON interface through which +power commands and policies can be sent. This functionality adds a dependency +on the Jansson library, and the Jansson development package must be installed +on the system before the JSON parsing functionality is included in the app. +This is achieved by: + + .. code-block:: javascript + + apt-get install libjansson-dev + +The command and package name may be different depending on your operating +system. It's worth noting that the app will successfully build without this +package present, but a warning is shown during compilation, and the JSON +parsing functionality will not be present in the app. + +Sending a command or policy to the power manager application is achieved by +simply opening a fifo file, writing a JSON string to that fifo, and closing +the file. + +The fifo is at /tmp/powermonitor/fifo + +The jason string can be a policy or instruction, and takes the following +format: + + .. code-block:: javascript + + {"packet_type": { + "pair_1": value, + "pair_2": value + }} + +The 'packet_type' header can contain one of two values, depending on +whether a policy or power command is being sent. The two possible values are +"policy" and "instruction", and the expected name-value pairs is different +depending on which type is being sent. + +The pairs are the format of standard JSON name-value pairs. The value type +varies between the different name/value pairs, and may be integers, strings, +arrays, etc. Examples of policies follow later in this document. The allowed +names and value types are as follows: + + +:Pair Name: "name" +:Description: Name of the VM or Host. Allows the parser to associate the + policy with the relevant VM or Host OS. +:Type: string +:Values: any valid string +:Required: yes +:Example: + + .. code-block:: javascript + + "name", "ubuntu2" + + +:Pair Name: "command" +:Description: The type of packet we're sending to the power manager. We can be + creating or destroying a policy, or sending a direct command to adjust + the frequency of a core, similar to the command line interface. +:Type: string +:Values: + + :CREATE: used when creating a new policy, + :DESTROY: used when removing a policy, + :POWER: used when sending an immediate command, max, min, etc. +:Required: yes +:Example: + + .. code-block:: javascript + + "command", "CREATE" + + +:Pair Name: "policy_type" +:Description: Type of policy to apply. Please see vm_power_manager documentation + for more information on the types of policies that may be used. +:Type: string +:Values: + + :TIME: Time-of-day policy. Frequencies of the relevant cores are + scaled up/down depending on busy and quiet hours. + :TRAFFIC: This policy takes statistics from the NIC and scales up + and down accordingly. + :WORKLOAD: This policy looks at how heavily loaded the cores are, + and scales up and down accordingly. + :BRANCH_RATIO: This out-of-band policy can look at the ratio between + branch hits and misses on a core, and is useful for detecting + how much packet processing a core is doing. +:Required: only for CREATE/DESTROY command +:Example: + + .. code-block:: javascript + + "policy_type", "TIME" + +:Pair Name: "busy_hours" +:Description: The hours of the day in which we scale up the cores for busy + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: javascript + + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ] + +:Pair Name: "quiet_hours" +:Description: The hours of the day in which we scale down the cores for quiet + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: javascript + + "quiet_hours":[ 2, 3, 4, 5, 6 ] + +:Pair Name: "avg_packet_thresh" +:Description: Threshold below which the frequency will be set to min for + the TRAFFIC policy. If the traffic rate is above this and below max, the + frequency will be set to medium. +:Type: integer +:Values: The number of packets below which the TRAFFIC policy applies the + minimum frequency, or medium frequency if between avg and max thresholds. +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: javascript + + "avg_packet_thresh": 100000 + +:Pair Name: "max_packet_thresh" +:Description: Threshold above which the frequency will be set to max for + the TRAFFIC policy +:Type: integer +:Values: The number of packets per interval above which the TRAFFIC policy + applies the maximum frequency +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: javascript + + "max_packet_thresh": 500000 + +:Pair Name: "core_list" +:Description: The cores to which to apply the policy. +:Type: array of integers +:Values: array with list of virtual CPUs. +:Required: only policy CREATE/DESTROY +:Example: + + .. code-block:: javascript + + "core_list":[ 10, 11 ] + +:Pair Name: "workload" +:Description: When our policy is of type WORKLOAD, we need to specify how + heavy our workload is. +:Type: string +:Values: + + :HIGH: For cores running workloads that require high frequencies + :MEDIUM: For cores running workloads that require medium frequencies + :LOW: For cores running workloads that require low frequencies +:Required: only for WORKLOAD policy types +:Example: + + .. code-block:: javascript + + "workload", "MEDIUM" + +:Pair Name: "mac_list" +:Description: When our policy is of type TRAFFIC, we need to specify the + MAC addresses that the host needs to monitor +:Type: string +:Values: array with a list of mac address strings. +:Required: only for TRAFFIC policy types +:Example: + + .. code-block:: javascript + + "mac_list":[ "de:ad:be:ef:01:01", "de:ad:be:ef:01:02" ] + +:Pair Name: "unit" +:Description: the type of power operation to apply in the command +:Type: string +:Values: + + :SCALE_MAX: Scale frequency of this core to maximum + :SCALE_MIN: Scale frequency of this core to minimum + :SCALE_UP: Scale up frequency of this core + :SCALE_DOWN: Scale down frequency of this core + :ENABLE_TURBO: Enable Turbo Boost for this core + :DISABLE_TURBO: Disable Turbo Boost for this core +:Required: only for POWER instruction +:Example: + + .. code-block:: javascript + + "unit", "SCALE_MAX" + +:Pair Name: "resource_id" +:Description: The core to which to apply the power command. +:Type: integer +:Values: valid core id for VM or host OS. +:Required: only POWER instruction +:Example: + + .. code-block:: javascript + + "resource_id": 10 + +JSON API Examples +~~~~~~~~~~~~~~~~~ + +Profile create example: + + .. code-block:: javascript + + {"policy": { + "name": "ubuntu", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11 ] + }} + +Profile destroy example: + + .. code-block:: javascript + + {"profile": { + "name": "ubuntu", + "command": "destroy", + }} + +Power command example: + + .. code-block:: javascript + + {"command": { + "name": "ubuntu", + "unit": "SCALE_MAX", + "resource_id": 10 + }} + +To send a JSON string to the Power Manager application, simply paste the +example JSON string into a text file and cat it into the fifo: + + .. code-block:: console + + cat file.json >/tmp/powermonitor/fifo + +The console of the Power Manager application should indicate the command that +was just received via the fifo. + Compiling and Running the Guest Applications --------------------------------------------
@@ -366,7 +646,7 @@ For compiling and running l3fwd-power, see :doc:`l3_forward_power_man`. The application is located in the ``guest_cli`` sub-directory under ``vm_power_manager``. -To build just the ``guest_vm_power_manager`` application: +To build just the ``guest_vm_power_manager`` application using ``make``: .. code-block:: console
@@ -375,6 +655,22 @@ To build just the ``guest_vm_power_manager`` application: cd ${RTE_SDK}/examples/vm_power_manager/guest_cli/ make +The resulting binary will be ${RTE_SDK}/build/examples/guest_cli + +To build just the ``vm_power_manager`` application using ``meson/ninja``: + +.. code-block:: console + + export RTE_SDK=/path/to/rte_sdk + cd ${RTE_SDK} + meson build + cd build + ninja + meson configure -Dexamples=vm_power_manager/guest_cli + ninja + +The resulting binary will be ${RTE_SDK}/build/examples/guest_cli + Running ~~~~~~~
Signature · 1 line
2.17.1
v7 cover add json power policy interface for containers
In reply to David HuntThe current vm_power_manager example app has the capability to accept power policies from virtual machines via virtio-serial channels. These power policies allow a virtual machine to give information to the power manager to allow the power manager take care of the power management of the virtual machine based on the information in the policy.
This power policy functionality is limited to virtual machines sending the policies to the power manager (which runs in the Host OS), and a solution was needed for additional methods of sending power policies to the power manager app.
The main use-case for this modification is for containers and host applications that wish to send polices to the power manager.
This patchset adds the capability to send power polices and power commands to the vm_power_manager app via JSON strings through a fifo on the file system.
For example, given the following file, policy.json:
{"policy": {
"name": "ubuntu2",
"command": "create",
"policy_type": "TIME",
"busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ],
"quiet_hours":[ 2, 3, 4, 5, 6 ],
"core_list":[ 11, 12, 13 ]
}}
Then running the command:
cat policy.json >/tmp/powermonitor/fifo
The policy is sent to the vm_power_manager. The power manager app then parses the JSON data, and inserts the policy into the array of policies.
Part of the patch series contains documentation updates to give all the details of the valid name-value pairs, the data types, etc.
Patch v2:
* Fixed review comments from Stephen Hemminger and Lei A Yao.
* Added a check in the Makefile for libjansson-dev. Will Warn user and build without JSON functionality if not present, will build including JSON functionality if it is present.
Patch v3:
* Added meson/ninja support for vm_power_manager and guest_cli apps
* Fixed compilation issue with guest_cli app
Patch v4:
* Split out some unrelated changes to separate patches in the set
* Some changes out of review by Anatoly (Thanks!)
Patch v5:
* Removed the directory with JSON examples, as they already exist in the documentation.
* Fixed some typos and formatting issues in the documentation.
* Changed the JSON examples in the documentation to 'javascript' causing the syntax to be highlighted nicely.
* Inherited the Acks from previous version.
Patch v6:
* Added ability to set WORKLOAD policy to LOW, MEDIUM, or HIGH. "workload": "MEDIUM"
* Added missing functionality to allow passing of a list of mac addresses for the TRAFFIC profile type. "mac_list":[ "de:ad:be:ef:01:01", "de:ad:be:ef:01:02" ]
* Updated docs to include both of the above additions.
Patch v7:
* Added release note update to the doc patch.
[01/10] examples/power: add checks around hypervisor [02/10] examples/power: allow for number of vms to be zero [03/10] lib/power: add changes for host commands/policies [04/10] examples/power: add necessary changes to guest app [05/10] examples/power: add host channel to power manager [06/10] examples/power: increase allowed number of clients [07/10] examples/power: add json string handling [08/10] examples/power: clean up verbose messages [09/10] examples/power: add meson/ninja build support [10/10] doc/vm_power_manager: add JSON interface API info
PATCH v7 1/10 examples/power: add checks around hypervisor
Allow vm_power_manager to run without requiring qemu to be present on the machine. This will be required for instances where the JSON interface is used for commands and polices, without any VMs present. A use case for this is a container enviromnent.
--- examples/vm_power_manager/channel_manager.c | 71 +++++++++++++-------- 1 file changed, 43 insertions(+), 28 deletions(-)
examples/vm_power_manager/channel_manager.c +43 -28
@@ -43,7 +43,8 @@ static unsigned char *global_cpumaps;static virVcpuInfo *global_vircpuinfo;static size_t global_maplen; -static unsigned global_n_host_cpus; +static unsigned int global_n_host_cpus; +static bool global_hypervisor_available;/* * Represents a single Virtual Machine
@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned vcpu) {struct virtual_machine_info *vm_info = (struct virtual_machine_info *)chan_info->priv_info; -return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); + +if (global_hypervisor_available && (vm_info !=NULL )) +return rte_atomic64_read (&vm_info->pcpu_mask[vcpu]); +else +return 0 ; } static inline int
@@ -559,6 +564,8 @@ get_all_vm(int *num_vm, int *num_vcpu)VIR_CONNECT_LIST_DOMAINS_PERSISTENT ;unsigned int domain_flag =VIR_DOMAIN_VCPU_CONFIG ; +if (!global_hypervisor_available) +return ;memset (global_cpumaps,0 ,CHANNEL_CMDS_MAX_CPUS *global_maplen);if (virNodeGetInfo (global_vir_conn_ptr, &node_info)) {
@@ -768,38 +775,42 @@ connect_hypervisor(const char *path) }return 0 ; } -int -channel_manager_init (const char *path) +channel_manager_init(const char *path __rte_unused) {virNodeInfo info;LIST_INIT (&vm_list_head);if (connect_hypervisor (path) <0 ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); -return -1 ; - } - - global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + global_n_host_cpus =64 ; + global_hypervisor_available =0 ; +RTE_LOG (INFO ,CHANNEL_MANAGER ,"Unable to initialize channel manager\n" ); + }else { + global_hypervisor_available =1 ; + + global_maplen =VIR_CPU_MAPLEN (CHANNEL_CMDS_MAX_CPUS ); + + global_vircpuinfo =rte_zmalloc (NULL , +sizeof (*global_vircpuinfo) * +CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); +if (global_vircpuinfo ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); + goto error; + } + global_cpumaps =rte_zmalloc (NULL , +CHANNEL_CMDS_MAX_CPUS * global_maplen, +RTE_CACHE_LINE_SIZE ); +if (global_cpumaps ==NULL ) + goto error; - global_vircpuinfo =rte_zmalloc (NULL ,sizeof (*global_vircpuinfo) * -CHANNEL_CMDS_MAX_CPUS ,RTE_CACHE_LINE_SIZE ); -if (global_vircpuinfo ==NULL ) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for CPU Info\n" ); - goto error; - } - global_cpumaps =rte_zmalloc (NULL ,CHANNEL_CMDS_MAX_CPUS * global_maplen, -RTE_CACHE_LINE_SIZE ); -if (global_cpumaps ==NULL ) { - goto error; +if (virNodeGetInfo (global_vir_conn_ptr, &info)) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); + goto error; + } + global_n_host_cpus = (unsigned int )info.cpus; } -if (virNodeGetInfo (global_vir_conn_ptr, &info)) { -RTE_LOG (ERR ,CHANNEL_MANAGER ,"Unable to retrieve node Info\n" ); - goto error; - } - global_n_host_cpus = (unsigned )info.cpus;if (global_n_host_cpus >CHANNEL_CMDS_MAX_CPUS ) { RTE_LOG(WARNING, CHANNEL_MANAGER, "The number of host CPUs(%u) exceeds the "
@@ -811,7 +822,8 @@ channel_manager_init(const char *path)return 0 ; error: -disconnect_hypervisor (); +if (global_hypervisor_available) +disconnect_hypervisor ();return -1 ; }
@@ -838,7 +850,10 @@ channel_manager_exit(void)rte_free (vm_info); } -rte_free (global_cpumaps); -rte_free (global_vircpuinfo); -disconnect_hypervisor (); +if (global_hypervisor_available) { +/* Only needed if hypervisor available */ +rte_free (global_cpumaps); +rte_free (global_vircpuinfo); +disconnect_hypervisor (); + } }
Signature · 1 line
2.17.1
PATCH v7 2/10 examples/power: allow for number of vms to be zero
In reply to David HuntPreviously the vm_power_manager app required to have some vms defined, so the call to get_all_vm() always set the noVms variable. Now we're accepting policies from the host OS (without any VMs defined), so it is now valid to have zero VMs. This patch initialises the relevant variables to zero just in case the call to get_all_vms() does not find any, so could return with the variables uninitialised.
--- examples/vm_power_manager/channel_monitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
examples/vm_power_manager/channel_monitor.c +1 -1
@@ -66,7 +66,7 @@ static void core_share_status(int pNo) { -int noVms, noVcpus, z, x, t; +int noVms =0 , noVcpus =0 , z, x, t;get_all_vm (&noVms, &noVcpus);
Signature · 1 line
2.17.1
PATCH v7 3/10 lib/power: add changes for host commands/policies
In reply to David HuntThis patch does a couple of things:
* Adds a new message type for removing policies (PKT_POLICY_REMOVE) Used when we want to remove a previously created policy.
* Adds a core_type bool to the channel packet struct to specify whether the type of core we want to control is cirtual or physical.
--- lib/librte_power/channel_commands.h | 5 +++++ 1 file changed, 5 insertions(+)
lib/librte_power/channel_commands.h +5 -0
@@ -19,6 +19,7 @@ extern "C" {#define CPU_POWER 1#define CPU_POWER_CONNECT 2#define PKT_POLICY 3 +#define PKT_POLICY_REMOVE 4/* CPU Power Command Scaling */ #define CPU_POWER_SCALE_UP 1
@@ -58,6 +59,9 @@ struct traffic {uint32_t max_max_packet_thresh; }; +#define CORE_TYPE_VIRTUAL 0 +#define CORE_TYPE_PHYSICAL 1 +struct channel_packet {uint64_t resource_id;/**< core_num, device */ uint32_t unit;/**< scale down/up/min/max */
@@ -70,6 +74,7 @@ struct channel_packet {uint8_t vcpu_to_control[MAX_VCPU_PER_VM ];uint8_t num_vcpu;struct timer_profile timer_policy; +bool core_type;enum workload workload;enum policy_to_use policy_to_use;struct t_boost_status t_boost_status;
Signature · 1 line
2.17.1
PATCH v7 4/10 examples/power: add necessary changes to guest app
In reply to David HuntThe changes here are minimal, as the guest app functionality is not changing at all, but there is a new element in the channel_packet struct that needs to have a default set (channel_packet->core_type).
--- examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 1 + 1 file changed, 1 insertion(+)
examples/vm_power_manager/guest_cli/vm_power_cli_guest.c +1 -0
@@ -92,6 +92,7 @@ set_policy_defaults(struct channel_packet *pkt) pkt->timer_policy.hours_to_use_traffic_profile[0 ] =8 ; pkt->timer_policy.hours_to_use_traffic_profile[1 ] =10 ; + pkt->core_type =CORE_TYPE_VIRTUAL ; pkt->workload =LOW ; pkt->policy_to_use =TIME ; pkt->command =PKT_POLICY ;
Signature · 1 line
2.17.1
PATCH v7 5/10 examples/power: add host channel to power manager
In reply to David HuntThis patch adds a fifo channel to the vm_power_manager app through which we can send commands and polices. Intended for sending JSON strings. The fifo is at /tmp/powermonitor/fifo
--- examples/vm_power_manager/channel_manager.c | 109 +++++++++++++++ examples/vm_power_manager/channel_manager.h | 17 +++ examples/vm_power_manager/channel_monitor.c | 142 +++++++++++++++----- examples/vm_power_manager/main.c | 2 + 4 files changed, 236 insertions(+), 34 deletions(-)
examples/vm_power_manager/channel_manager.c +109 -0
@@ -13,6 +13,7 @@#include <sys/queue.h> #include <sys/types.h> +#include <sys/stat.h> #include <sys/socket.h> #include <sys/select.h>
@@ -284,6 +285,38 @@ open_non_blocking_channel(struct channel_info *info)return 0 ; } +static int +open_host_channel (struct channel_info *info) +{ +int flags; + + info->fd =open (info->channel_path,O_RDWR |O_RSYNC ); +if (info->fd ==-1 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error(%s) opening fifo for '%s'\n" , +strerror (errno), + info->channel_path); +return -1 ; + } + +/* Get current flags */ + flags =fcntl (info->fd,F_GETFL ,0 ); +if (flags <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER ,"Error(%s) fcntl get flags socket for" +"'%s'\n" ,strerror (errno), info->channel_path); +return 1 ; + } +/* Set to Non Blocking */ + flags |=O_NONBLOCK ; +if (fcntl (info->fd,F_SETFL , flags) <0 ) { +RTE_LOG (WARNING ,CHANNEL_MANAGER , +"Error(%s) setting non-blocking " +"socket for '%s'\n" , +strerror (errno), info->channel_path); +return -1 ; + } +return 0 ; +} +static int setup_channel_info (struct virtual_machine_info **vm_info_dptr,struct channel_info **chan_info_dptr,unsigned channel_num)
@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr, chan_info->channel_num = channel_num; chan_info->priv_info = (void *)vm_info; chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_BINARY ;if (open_non_blocking_channel (chan_info) <0 ) { RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open channel: " "'%s' for VM '%s'\n",
@@ -316,6 +350,42 @@ setup_channel_info(struct virtual_machine_info **vm_info_dptr,return 0 ; } +static void +fifo_path (char *dst,unsigned int len) +{ +snprintf (dst, len,"%sfifo" ,CHANNEL_MGR_SOCKET_PATH ); +} + +static int +setup_host_channel_info (struct channel_info **chan_info_dptr, +unsigned int channel_num) +{ +struct channel_info *chan_info = *chan_info_dptr; + + chan_info->channel_num = channel_num; + chan_info->priv_info = (void *)NULL ; + chan_info->status =CHANNEL_MGR_CHANNEL_DISCONNECTED ; + chan_info->type =CHANNEL_TYPE_JSON ; + +fifo_path (chan_info->channel_path,sizeof (chan_info->channel_path)); + +if (open_host_channel (chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could not open host channel: " +"'%s'\n" , + chan_info->channel_path); +return -1 ; + } +if (add_channel_to_monitor (&chan_info) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Could add channel: " +"'%s' to epoll ctl\n" , + chan_info->channel_path); +return -1 ; + + } + chan_info->status =CHANNEL_MGR_CHANNEL_CONNECTED ; +return 0 ; +} +int add_all_channels (const char *vm_name) {
@@ -470,6 +540,45 @@ add_channels(const char *vm_name, unsigned *channel_list,return num_channels_enabled; } +int +add_host_channel (void ) +{ +struct channel_info *chan_info; +char socket_path[PATH_MAX ]; +int num_channels_enabled =0 ; +int ret; + +fifo_path (socket_path,sizeof (socket_path)); + + ret =mkfifo (socket_path,0660 ); +if ((errno !=EEXIST ) && (ret <0 )) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Cannot create fifo '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + +if (access (socket_path,F_OK ) <0 ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Channel path '%s' error: " +"%s\n" , socket_path,strerror (errno)); +return 0 ; + } + chan_info =rte_malloc (NULL ,sizeof (*chan_info),0 ); +if (chan_info ==NULL ) { +RTE_LOG (ERR ,CHANNEL_MANAGER ,"Error allocating memory for " +"channel '%s'\n" , socket_path); +return 0 ; + } +snprintf (chan_info->channel_path, +sizeof (chan_info->channel_path),"%s" , socket_path); +if (setup_host_channel_info (&chan_info,0 ) <0 ) { +rte_free (chan_info); +return 0 ; + } + num_channels_enabled++; + +return num_channels_enabled; +} +int remove_channel (struct channel_info **chan_info_dptr) {
examples/vm_power_manager/channel_manager.h +17 -0
@@ -54,6 +54,13 @@ enum channel_status { CHANNEL_MGR_CHANNEL_DISCONNECTED = 0,CHANNEL_MGR_CHANNEL_DISABLED , CHANNEL_MGR_CHANNEL_PROCESSING}; +/* Communication Channel Type */ +enum channel_type { +CHANNEL_TYPE_BINARY =0 , +CHANNEL_TYPE_INI , +CHANNEL_TYPE_JSON +}; +/* VM libvirt(qemu/KVM) connection status */ enum vm_status {CHANNEL_MGR_VM_INACTIVE =0 ,CHANNEL_MGR_VM_ACTIVE };
@@ -66,6 +73,7 @@ struct channel_info {volatile uint32_t status;/**< Connection status(enum channel_status) */ int fd;/**< AF_UNIX socket fd */ unsigned channel_num;/**< CHANNEL_MGR_SOCKET_PATH/<vm_name>.channel_num */ +enum channel_type type;/**< Binary, ini, json, etc. */ void *priv_info;/**< Pointer to private info, do not modify */ };
@@ -226,6 +234,15 @@ int add_all_channels(const char *vm_name);int add_channels (const char *vm_name,unsigned *channel_list,unsigned num_channels); +/** +* Set up a fifo by which host applications can send command an policies +* through a fifo to the vm_power_manager +* +* @return +* - 0 for success +*/ +int add_host_channel (void ); +/** * Remove a channel definition from the channel manager. This must only be * called from the channel monitor thread.
examples/vm_power_manager/channel_monitor.c +108 -34
221 lines not on this page · raw message
examples/vm_power_manager/main.c +2 -0
@@ -421,6 +421,8 @@ main(int argc, char **argv)return -1 ; } +add_host_channel (); +printf ("Running core monitor on lcore id %d\n" , lcore_id);rte_eal_remote_launch (run_core_monitor,NULL , lcore_id);
Signature · 1 line
2.17.1
PATCH v7 6/10 examples/power: increase allowed number of clients
In reply to David HuntNow that we're handling host policies, containers and virtual machines, we'll rename MAX_VMS to MAX_CLIENTS, and increase from 4 to 64
--- examples/vm_power_manager/channel_manager.h | 4 ++-- examples/vm_power_manager/channel_monitor.c | 10 +++++----- 2 files changed, 7 insertions(+), 7 deletions(-)
examples/vm_power_manager/channel_manager.h +2 -2
@@ -37,7 +37,7 @@ struct sockaddr_un _sockaddr_un;#define UNIX_PATH_MAX sizeof(_sockaddr_un.sun_path)#endif -#define MAX_VMS 4 +#define MAX_CLIENTS 64#define MAX_VCPUS 20
@@ -47,7 +47,7 @@ struct libvirt_vm_info {uint8_t num_cpus; }; -struct libvirt_vm_info lvm_info[MAX_VMS ]; +struct libvirt_vm_info lvm_info[MAX_CLIENTS ];/* Communication Channel Status */ enum channel_status {CHANNEL_MGR_CHANNEL_DISCONNECTED =0 ,CHANNEL_MGR_CHANNEL_CONNECTED ,
examples/vm_power_manager/channel_monitor.c +5 -5
@@ -41,7 +41,7 @@ static volatile unsigned run_loop = 1;static int global_event_fd;static unsigned int policy_is_set;static struct epoll_event *global_events_list; -static struct policy policies[MAX_VMS ]; +static struct policy policies[MAX_CLIENTS ];void channel_monitor_exit (void ) {
@@ -199,7 +199,7 @@ update_policy(struct channel_packet *pkt)RTE_LOG (INFO ,CHANNEL_MONITOR ,"Applying policy for %s\n" , pkt->vm_name); -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) {/* Copy the contents of *pkt into the policy.pkt */ policies[i].pkt = *pkt;
@@ -214,7 +214,7 @@ update_policy(struct channel_packet *pkt) } }if (!updated) { -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (policies[i].enabled ==0 ) { policies[i].pkt = *pkt;get_pcpu_to_control (&policies[i]);
@@ -238,7 +238,7 @@ remove_policy(struct channel_packet *pkt __rte_unused)* Disabling the policy is simply a case of setting * enabled to 0 */ -for (i =0 ; i <MAX_VMS ; i++) { +for (i =0 ; i <MAX_CLIENTS ; i++) {if (strcmp (policies[i].pkt.vm_name, pkt->vm_name) ==0 ) { policies[i].enabled =0 ;return 0 ;
@@ -609,7 +609,7 @@ run_channel_monitor(void)if (policy_is_set) {int j; -for (j =0 ; j <MAX_VMS ; j++) { +for (j =0 ; j <MAX_CLIENTS ; j++) {if (policies[j].enabled ==1 )apply_policy (&policies[j]); }
Signature · 1 line
2.17.1
PATCH v7 7/10 examples/power: add json string handling
In reply to David HuntAdd JSON string handling to vm_power_manager for JSON strings received through the fifo. The format of the JSON strings are detailed in the next patch, the vm_power_manager user guide documentation updates.
This patch introduces a new dependency on Jansson, a C library for encoding, decoding and manipulating JSON data. To compile the sample app you now need to have installed libjansson4 and libjansson-dev (these may be named slightly differently depending on your Operating System)
--- examples/vm_power_manager/Makefile | 6 + examples/vm_power_manager/channel_monitor.c | 371 ++++++++++++++++++-- 2 files changed, 352 insertions(+), 25 deletions(-)
examples/vm_power_manager/Makefile +6 -0
@@ -31,6 +31,12 @@ CFLAGS += $(WERROR_FLAGS) LDLIBS += -lvirt +JANSSON := $(shell pkg-config --exists jansson; echo $$?) +ifeq ($(JANSSON), 0) +LDLIBS += $(shell pkg-config --libs jansson) +CFLAGS += -DUSE_JANSSON +endif + ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
examples/vm_power_manager/channel_monitor.c +346 -25
406 lines not on this page · raw message
Signature · 1 line
2.17.1
PATCH v7 8/10 examples/power: clean up verbose messages
In reply to David HuntSome messages appearing several times a second, removing as they are unnecessary. Other less severe messages change from INFO to DEBUG
--- examples/vm_power_manager/channel_monitor.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-)
examples/vm_power_manager/channel_monitor.c +5 -14
@@ -361,7 +361,7 @@ get_pcpu_to_control(struct policy *pol) ci =get_core_info (); -RTE_LOG (INFO ,CHANNEL_MONITOR , +RTE_LOG (DEBUG ,CHANNEL_MONITOR ,"Looking for pcpu for %s\n" , pol->pkt.vm_name);/*
@@ -528,8 +528,6 @@ apply_traffic_profile(struct policy *pol) diff =get_pkt_diff (pol); -RTE_LOG (INFO ,CHANNEL_MONITOR ,"Applying traffic profile\n" ); -if (diff >= (pol->pkt.traffic_policy.max_max_packet_thresh)) {for (count =0 ; count < pol->pkt.num_vcpu; count++) {if (pol->core_share[count].status !=1 )
@@ -573,9 +571,6 @@ apply_time_profile(struct policy *pol)if (pol->core_share[count].status !=1 ) {power_manager_scale_core_max ( pol->core_share[count].pcpu); -RTE_LOG (INFO ,CHANNEL_MONITOR , -"Scaling up core %d to max\n" , - pol->core_share[count].pcpu); } }break ;
@@ -585,9 +580,6 @@ apply_time_profile(struct policy *pol)if (pol->core_share[count].status !=1 ) {power_manager_scale_core_min ( pol->core_share[count].pcpu); -RTE_LOG (INFO ,CHANNEL_MONITOR , -"Scaling down core %d to min\n" , - pol->core_share[count].pcpu); } }break ;
@@ -649,8 +641,6 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info)if (chan_info ==NULL )return -1 ; -RTE_LOG (INFO ,CHANNEL_MONITOR ,"Processing Request %s\n" , pkt->vm_name); -if (rte_atomic32_cmpset (&(chan_info->status),CHANNEL_MGR_CHANNEL_CONNECTED ,CHANNEL_MGR_CHANNEL_PROCESSING ) ==0 )return -1 ;
@@ -719,8 +709,8 @@ process_request(struct channel_packet *pkt, struct channel_info *chan_info) }if (pkt->command ==PKT_POLICY ) { -RTE_LOG (INFO ,CHANNEL_MONITOR , -"\nProcessing Policy request\n" ); +RTE_LOG (INFO ,CHANNEL_MONITOR ,"Processing policy request %s\n" , + pkt->vm_name);update_policy (pkt); policy_is_set =1 ; }
@@ -904,7 +894,8 @@ run_channel_monitor(void) global_events_list[i].data.ptr;if ((global_events_list[i].events &EPOLLERR ) || (global_events_list[i].events &EPOLLHUP )) { -RTE_LOG (DEBUG ,CHANNEL_MONITOR ,"Remote closed connection for " +RTE_LOG (INFO ,CHANNEL_MONITOR , +"Remote closed connection for " "channel '%s'\n" , chan_info->channel_path);remove_channel (&chan_info);
Signature · 1 line
2.17.1
PATCH v7 9/10 examples/power: add meson/ninja build support
In reply to David HuntAdd meson.build in vm_power_manager and the guest_cli subdirectory. Building can be achieved by going to the build directory, and using
meson configure -Dexamples=vm_power_manager,vm_power_manager/guest_cli
Then, when ninja is invoked, it will build dpdk-vm_power_manger and dpdk-guest_cli
Work still needs to be done on the meson build system to handles the case where the target list of example apps is defined as 'all'. That will come in a future patch.
--- .../vm_power_manager/guest_cli/meson.build | 21 +++++++++++ examples/vm_power_manager/meson.build | 37 ++++++++++++++++++- 2 files changed, 56 insertions(+), 2 deletions(-) create mode 100644 examples/vm_power_manager/guest_cli/meson.build
examples/vm_power_manager/guest_cli/meson.build new file +21 -0
@@ -0,0 +1,21 @@ +# SPDX-License-Identifier: BSD-3-Clause +# Copyright(c) 2018 Intel Corporation + +# meson file, for building this example as part of a main DPDK build. +# +# To build this example as a standalone application with an already-installed +# DPDK instance, use 'make' + +# Setting the name here because the default name will conflict with the +# vm_power_manager app because of the way the directories are parsed. +name = 'guest_cli' + +deps += ['power'] + +sources = files( + 'main.c', 'parse.c', 'vm_power_cli_guest.c' +) + +opt_dep = cc.find_library('virt', required : false) +build = opt_dep.found() +ext_deps += opt_dep
examples/vm_power_manager/meson.build +35 -2
@@ -6,5 +6,38 @@ # To build this example as a standalone application with an already-installed # DPDK instance, use 'make' -# Example app currently unsupported by meson build -build = false +if dpdk_conf.has('RTE_LIBRTE_BNXT_PMD') + deps += ['pmd_bnxt'] +endif + +if dpdk_conf.has('RTE_LIBRTE_I40E_PMD') + deps += ['pmd_i40e'] +endif + +if dpdk_conf.has('RTE_LIBRTE_IXGBE_PMD') + deps += ['pmd_ixgbe'] +endif + +deps += ['power'] + + +sources = files( + 'channel_manager.c', 'channel_monitor.c', 'main.c', 'parse.c', 'power_manager.c', 'vm_power_cli.c' +) + +# If we're on X86, pull in the x86 code for the branch monitor algo. +if dpdk_conf.has('RTE_ARCH_X86_64') + sources += files('oob_monitor_x86.c') +else + sources += files('oob_monitor_nop.c') +endif + +opt_dep = cc.find_library('virt', required : false) +build = opt_dep.found() +ext_deps += opt_dep + +opt_dep = dependency('jansson', required : false) +if opt_dep.found() + ext_deps += opt_dep + cflags += '-DUSE_JANSSON' +endif
Signature · 1 line
2.17.1
PATCH v7 10/10 doc/vm_power_manager: add JSON interface API info
In reply to David Hunt* added JSON interface API info
* added meson/ninja build info
* added Release Note changes
--- doc/guides/rel_notes/release_18_11.rst | 8 + .../sample_app_ug/vm_power_management.rst | 300 +++++++++++++++++- 2 files changed, 306 insertions(+), 2 deletions(-)
doc/guides/rel_notes/release_18_11.rst +8 -0
@@ -155,6 +155,14 @@ New Features the SW eventdev PMD, sacrifices load balancing performance to gain better event scheduling throughput and scalability. +* **Added JSON power policy interface for containers .** + + Extended the Power Library and vm_power_manger sample app to allow power + policies to be submitted via a FIFO using JSON formatted strings. Previously + limited to Virtual Machines, this feature extends power policy functionality + to containers and host applications that need to have their cores frequency + controlled based on the rules contained in the policy. + * **Added ability to switch queue deferred start flag on testpmd app.** Added a console command to testpmd app, giving ability to switch
doc/guides/sample_app_ug/vm_power_management.rst +298 -2
330 lines not on this page · raw message
Signature · 1 line
2.17.1
Re: [PATCH v7 10/10] doc/vm_power_manager: add JSON interface API info
17/10/2018 15:05, David Hunt:
Quoted 1 line
* added JSON interface API info
Should be in patch 7
Quoted 1 line
* added meson/ninja build info
Should be in patch 9
Quoted 1 line
* added Release Note changes
Should be in patch 7
Quoted 2 lines
Signed-off-by David Hunt <[email protected]>Acked-by Marko Kovacevic <[email protected]>
17/10/2018 15:05, David Hunt:
Quoted 10 lines
[01/10] examples/power: add checks around hypervisor [02/10] examples/power: allow for number of vms to be zero [03/10] lib/power: add changes for host commands/policies [04/10] examples/power: add necessary changes to guest app [05/10] examples/power: add host channel to power manager [06/10] examples/power: increase allowed number of clients [07/10] examples/power: add json string handling [08/10] examples/power: clean up verbose messages [09/10] examples/power: add meson/ninja build support [10/10] doc/vm_power_manager: add JSON interface API info
Applied (with doc spread in other patches), thanks.