Patch Comment List
List patch comments
GET /api/patches/40766/comments/?format=api
[ { "id": 82331, "web_url": "http://patches.dpdk.org/comment/82331/", "msgid": "<181b45a2-93cc-5700-5f9e-2dfdf474e38c@intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/181b45a2-93cc-5700-5f9e-2dfdf474e38c@intel.com", "date": "2018-06-18T10:36:15", "subject": "Re: [dpdk-dev] [PATCH 22/22] examples/devmgm_mp: add simple device\n\tmanagement sample", "submitter": { "id": 4, "url": "http://patches.dpdk.org/api/people/4/?format=api", "name": "Anatoly Burakov", "email": "anatoly.burakov@intel.com" }, "content": "On 07-Jun-18 1:38 PM, Qi Zhang wrote:\n> The sample code demonstrate device (ethdev only) management\n> at multi-process envrionment. User can attach/detach a device\n> on primary process and see it is synced on secondary process\n> automatically, also user can lock a device to prevent it be\n> detached or unlock it to go back to default behaviour.\n> \n> How to start?\n> ./devmgm_mp --proc-type=auto\n> \n> Command Line Example:\n> \n>> help\n>> list\n> \n> /* attach a af_packet vdev */\n>> attach net_af_packet,iface=eth0\n> \n> /* detach port 0 */\n>> detach 0\n> \n> /* attach a private af_packet vdev (secondary process only)*/\n>> attachp net_af_packet,iface=eth0\n> \n> /* detach a private device (secondary process only) */\n>> detachp 0\n> \n> /* lock port 0 */\n>> lock 0\n> \n> /* unlock port 0 */\n>> unlock 0\n> \n> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>\n> ---\n\nI think the \"devmgm_mp\" is not a descriptive enough name. What this \nexample demonstrates, is device hotplug. So how about naming the example \napp \"hotplug\"? (or \"mp_hotplug\" to indicate that it specifically sets \nout to demonstrate multiprocess hotplug)\n\n> examples/devmgm_mp/Makefile | 64 +++++++\n> examples/devmgm_mp/commands.c | 383 +++++++++++++++++++++++++++++++++++++++++\n> examples/devmgm_mp/commands.h | 10 ++\n> examples/devmgm_mp/main.c | 41 +++++\n> examples/devmgm_mp/meson.build | 11 ++\n> 5 files changed, 509 insertions(+)\n> create mode 100644 examples/devmgm_mp/Makefile\n> create mode 100644 examples/devmgm_mp/commands.c\n> create mode 100644 examples/devmgm_mp/commands.h\n> create mode 100644 examples/devmgm_mp/main.c\n> create mode 100644 examples/devmgm_mp/meson.build\n> \n\n<snip>\n\n> +#include <stdio.h>\n> +#include <stdint.h>\n> +#include <string.h>\n> +#include <stdlib.h>\n> +#include <stdarg.h>\n> +#include <errno.h>\n> +#include <netinet/in.h>\n> +#include <termios.h>\n> +#ifndef __linux__\n> +\t#ifdef __FreeBSD__\n> +\t\t#include <sys/socket.h>\n> +\t#else\n> +\t\t#include <net/socket.h>\n> +\t#endif\n> +#endif\n\nThis seems like a weird define. Care to elaborate why are we checking \nfor __linux__ not being defined?\n\nIf you're trying to differentiate between Linux and FreeBSD, there's a \nreadly RTE_EXEC_ENV_* config options, e.g.\n\n#ifdef RTE_EXEC_ENV_LINUXAPP\n// linux defines\n#endif\n#ifdef RTE_EXEC_ENV_BSDAPP\n// bsd defines\n#endif\n\nor something to that effect.\n\n> +\n> +#include <cmdline_rdline.h>\n> +#include <cmdline_parse.h>\n> +#include <cmdline_parse_ipaddr.h>\n> +#include <cmdline_parse_num.h>\n> +#include <cmdline_parse_string.h>\n> +#include <cmdline.h>\n> +#include <rte_ethdev.h>\n\nGenerally (and as per DPDK coding guidelines), we prefer defines ordered \nas follows:\n\n1) system defines enclosed in brackets\n2) DPDK defines (rte_blah) enclosed in brackets\n3) private/application-specific defines enclosed in quotes.\n\nAll three groups should be separated by newline.\n\nSo, these defines should've read as:\n\n#include <stdblah.h>\n#include <sys/blah.h>\n\n#include <rte_blah.h>\n#include <rte_foo.h>\n\n#include \"cmdline_blah.h\"\n#include \"cmdline_foo.h\"\n\n> +\n> +/**********************************************************/\n> +\n> +struct cmd_help_result {\n> +\tcmdline_fixed_string_t help;\n> +};\n> +\n> +static void cmd_help_parsed(__attribute__((unused)) void *parsed_result,\n\n<snip>\n\n> +{\n> +\tuint16_t port_id;\n> +\tchar dev_name[RTE_DEV_NAME_MAX_LEN];\n> +\n> +\tcmdline_printf(cl, \"list all etherdev\\n\");\n> +\n> +\tRTE_ETH_FOREACH_DEV(port_id) {\n> +\t\trte_eth_dev_get_name_by_port(port_id, dev_name);\n> +\t\t/* Secondary process's ethdev->state may not be\n> +\t\t * updated after detach on primary process, but\n> +\t\t * ethdev->data should already be reset, so\n> +\t\t * use strlen(dev_name) == 0 to know the port is\n> +\t\t * not used.\n> +\t\t *\n> +\t\t * TODO: Secondary process should be informed when a\n> +\t\t * port is released on primary through mp channel.\n> +\t\t */\n\nThat seems like a weird thing to leave out for TODO - it looks like an \nAPI deficiency. Can this be automatically updated on multiprocess \nhotplug sync, or somehow managed inside RTE_ETH_FOREACH_DEV?\n\nAs i understand, per-process ethdev list is not protected by any locks, \nso doing this is racy. Since this is a multiprocess hotplug example app, \nit should demonstrate best practices. So, either RTE_ETH_FOREACH_DEV \nshould be fixed to handle this case, or the application should \ndemonstrate how to properly synchronize access to local device list. The \nlatter is probably better as adding locking around ethdev device list is \noutside the scope of this patchset.\n\n> +\t\tif (strlen(dev_name) > 0)\n> +\t\t\tcmdline_printf(cl, \"%d\\t%s\\n\", port_id, dev_name);\n> +\t\telse\n> +\t\t\tprintf(\"empty dev_name is not expected!\\n\");\n> +\t}\n\n<snip>\n\n> +#include \"commands.h\"\n> +\n> +int main(int argc, char **argv)\n> +{\n> +\tint ret;\n> +\tstruct cmdline *cl;\n> +\n> +\tret = rte_eal_init(argc, argv);\n> +\tif (ret < 0)\n> +\t\trte_panic(\"Cannot init EAL\\n\");\n> +\n> +\tcl = cmdline_stdin_new(main_ctx, \"example> \");\n> +\tif (cl == NULL)\n> +\t\trte_panic(\"Cannot create cmdline instance\\n\");\n> +\tcmdline_interact(cl);\n> +\tcmdline_stdin_exit(cl);\n> +\n> +\treturn 0;\n\nApplication should call rte_eal_cleanup() before exit. Otherwise, each \nsecondary started and stopped will leak memory.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id AA4C21AFF;\n\tMon, 18 Jun 2018 12:36:21 +0200 (CEST)", "from mga18.intel.com (mga18.intel.com [134.134.136.126])\n\tby dpdk.org (Postfix) with ESMTP id 43A3A1559\n\tfor <dev@dpdk.org>; Mon, 18 Jun 2018 12:36:19 +0200 (CEST)", "from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t18 Jun 2018 03:36:18 -0700", "from aburakov-mobl.ger.corp.intel.com (HELO [10.252.30.40])\n\t([10.252.30.40])\n\tby fmsmga001.fm.intel.com with ESMTP; 18 Jun 2018 03:36:15 -0700" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.51,238,1526367600\"; d=\"scan'208\";a=\"65032603\"", "To": "Qi Zhang <qi.z.zhang@intel.com>, thomas@monjalon.net", "Cc": "konstantin.ananyev@intel.com, dev@dpdk.org, bruce.richardson@intel.com, \n\tferruh.yigit@intel.com, benjamin.h.shelton@intel.com,\n\tnarender.vangati@intel.com", "References": "<20180607123849.14439-1-qi.z.zhang@intel.com>\n\t<20180607123849.14439-23-qi.z.zhang@intel.com>", "From": "\"Burakov, Anatoly\" <anatoly.burakov@intel.com>", "Message-ID": "<181b45a2-93cc-5700-5f9e-2dfdf474e38c@intel.com>", "Date": "Mon, 18 Jun 2018 11:36:15 +0100", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.8.0", "MIME-Version": "1.0", "In-Reply-To": "<20180607123849.14439-23-qi.z.zhang@intel.com>", "Content-Type": "text/plain; charset=utf-8; format=flowed", "Content-Language": "en-US", "Content-Transfer-Encoding": "7bit", "Subject": "Re: [dpdk-dev] [PATCH 22/22] examples/devmgm_mp: add simple device\n\tmanagement sample", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 82512, "web_url": "http://patches.dpdk.org/comment/82512/", "msgid": "<039ED4275CED7440929022BC67E706115323B90F@SHSMSX103.ccr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/039ED4275CED7440929022BC67E706115323B90F@SHSMSX103.ccr.corp.intel.com", "date": "2018-06-22T06:49:56", "subject": "Re: [dpdk-dev] [PATCH 22/22] examples/devmgm_mp: add simple device\n\tmanagement sample", "submitter": { "id": 504, "url": "http://patches.dpdk.org/api/people/504/?format=api", "name": "Qi Zhang", "email": "qi.z.zhang@intel.com" }, "content": "Hi Anatoly:\n\n> -----Original Message-----\n> From: Burakov, Anatoly\n> Sent: Monday, June 18, 2018 6:36 PM\n> To: Zhang, Qi Z <qi.z.zhang@intel.com>; thomas@monjalon.net\n> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org;\n> Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh\n> <ferruh.yigit@intel.com>; Shelton, Benjamin H\n> <benjamin.h.shelton@intel.com>; Vangati, Narender\n> <narender.vangati@intel.com>\n> Subject: Re: [PATCH 22/22] examples/devmgm_mp: add simple device\n> management sample\n> \n> On 07-Jun-18 1:38 PM, Qi Zhang wrote:\n> > The sample code demonstrate device (ethdev only) management at\n> > multi-process envrionment. User can attach/detach a device on primary\n> > process and see it is synced on secondary process automatically, also\n> > user can lock a device to prevent it be detached or unlock it to go\n> > back to default behaviour.\n> >\n> > How to start?\n> > ./devmgm_mp --proc-type=auto\n> >\n> > Command Line Example:\n> >\n> >> help\n> >> list\n> >\n> > /* attach a af_packet vdev */\n> >> attach net_af_packet,iface=eth0\n> >\n> > /* detach port 0 */\n> >> detach 0\n> >\n> > /* attach a private af_packet vdev (secondary process only)*/\n> >> attachp net_af_packet,iface=eth0\n> >\n> > /* detach a private device (secondary process only) */\n> >> detachp 0\n> >\n> > /* lock port 0 */\n> >> lock 0\n> >\n> > /* unlock port 0 */\n> >> unlock 0\n> >\n> > Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>\n> > ---\n> \n> I think the \"devmgm_mp\" is not a descriptive enough name. What this\n> example demonstrates, is device hotplug. So how about naming the example\n> app \"hotplug\"? (or \"mp_hotplug\" to indicate that it specifically sets out to\n> demonstrate multiprocess hotplug)\n\n\nOk, I saw all the multi-process samples are in examples/multi_process, so I think this the right place to add\nit could be \"hotplug_mp\" to follow other samples naming rule.\n> \n> > examples/devmgm_mp/Makefile | 64 +++++++\n> > examples/devmgm_mp/commands.c | 383\n> +++++++++++++++++++++++++++++++++++++++++\n> > examples/devmgm_mp/commands.h | 10 ++\n> > examples/devmgm_mp/main.c | 41 +++++\n> > examples/devmgm_mp/meson.build | 11 ++\n> > 5 files changed, 509 insertions(+)\n> > create mode 100644 examples/devmgm_mp/Makefile\n> > create mode 100644 examples/devmgm_mp/commands.c\n> > create mode 100644 examples/devmgm_mp/commands.h\n> > create mode 100644 examples/devmgm_mp/main.c\n> > create mode 100644 examples/devmgm_mp/meson.build\n> >\n> \n> <snip>\n> \n> > +#include <stdio.h>\n> > +#include <stdint.h>\n> > +#include <string.h>\n> > +#include <stdlib.h>\n> > +#include <stdarg.h>\n> > +#include <errno.h>\n> > +#include <netinet/in.h>\n> > +#include <termios.h>\n> > +#ifndef __linux__\n> > +\t#ifdef __FreeBSD__\n> > +\t\t#include <sys/socket.h>\n> > +\t#else\n> > +\t\t#include <net/socket.h>\n> > +\t#endif\n> > +#endif\n> \n> This seems like a weird define. Care to elaborate why are we checking for\n> __linux__ not being defined?\n\nOK, this is copy from exist sample code :), I will clean up the header file in v3.\n\n> \n> If you're trying to differentiate between Linux and FreeBSD, there's a readly\n> RTE_EXEC_ENV_* config options, e.g.\n> \n> #ifdef RTE_EXEC_ENV_LINUXAPP\n> // linux defines\n> #endif\n> #ifdef RTE_EXEC_ENV_BSDAPP\n> // bsd defines\n> #endif\n> \n> or something to that effect.\n> \n> > +\n> > +#include <cmdline_rdline.h>\n> > +#include <cmdline_parse.h>\n> > +#include <cmdline_parse_ipaddr.h>\n> > +#include <cmdline_parse_num.h>\n> > +#include <cmdline_parse_string.h>\n> > +#include <cmdline.h>\n> > +#include <rte_ethdev.h>\n> \n> Generally (and as per DPDK coding guidelines), we prefer defines ordered as\n> follows:\n> \n> 1) system defines enclosed in brackets\n> 2) DPDK defines (rte_blah) enclosed in brackets\n> 3) private/application-specific defines enclosed in quotes.\n> \n> All three groups should be separated by newline.\n> \n> So, these defines should've read as:\n> \n> #include <stdblah.h>\n> #include <sys/blah.h>\n> \n> #include <rte_blah.h>\n> #include <rte_foo.h>\n> \n> #include \"cmdline_blah.h\"\n> #include \"cmdline_foo.h\"\n\nGot it, thanks\n\n> \n> > +\n> > +/**********************************************************/\n> > +\n> > +struct cmd_help_result {\n> > +\tcmdline_fixed_string_t help;\n> > +};\n> > +\n> > +static void cmd_help_parsed(__attribute__((unused)) void\n> > +*parsed_result,\n> \n> <snip>\n> \n> > +{\n> > +\tuint16_t port_id;\n> > +\tchar dev_name[RTE_DEV_NAME_MAX_LEN];\n> > +\n> > +\tcmdline_printf(cl, \"list all etherdev\\n\");\n> > +\n> > +\tRTE_ETH_FOREACH_DEV(port_id) {\n> > +\t\trte_eth_dev_get_name_by_port(port_id, dev_name);\n> > +\t\t/* Secondary process's ethdev->state may not be\n> > +\t\t * updated after detach on primary process, but\n> > +\t\t * ethdev->data should already be reset, so\n> > +\t\t * use strlen(dev_name) == 0 to know the port is\n> > +\t\t * not used.\n> > +\t\t *\n> > +\t\t * TODO: Secondary process should be informed when a\n> > +\t\t * port is released on primary through mp channel.\n> > +\t\t */\n> \n> That seems like a weird thing to leave out for TODO - it looks like an API\n> deficiency. Can this be automatically updated on multiprocess hotplug sync, or\n> somehow managed inside RTE_ETH_FOREACH_DEV?\n> \n> As i understand, per-process ethdev list is not protected by any locks, so doing\n> this is racy. Since this is a multiprocess hotplug example app, it should\n> demonstrate best practices. So, either RTE_ETH_FOREACH_DEV should be\n> fixed to handle this case, or the application should demonstrate how to\n> properly synchronize access to local device list. The latter is probably better as\n> adding locking around ethdev device list is outside the scope of this patchset.\n\nAll this comment should be removed since TODO already done :)\nActually, we guarantee device be detached from secondary before primary.\n\n> \n> > +\t\tif (strlen(dev_name) > 0)\n> > +\t\t\tcmdline_printf(cl, \"%d\\t%s\\n\", port_id, dev_name);\n> > +\t\telse\n> > +\t\t\tprintf(\"empty dev_name is not expected!\\n\");\n> > +\t}\n> \n> <snip>\n> \n> > +#include \"commands.h\"\n> > +\n> > +int main(int argc, char **argv)\n> > +{\n> > +\tint ret;\n> > +\tstruct cmdline *cl;\n> > +\n> > +\tret = rte_eal_init(argc, argv);\n> > +\tif (ret < 0)\n> > +\t\trte_panic(\"Cannot init EAL\\n\");\n> > +\n> > +\tcl = cmdline_stdin_new(main_ctx, \"example> \");\n> > +\tif (cl == NULL)\n> > +\t\trte_panic(\"Cannot create cmdline instance\\n\");\n> > +\tcmdline_interact(cl);\n> > +\tcmdline_stdin_exit(cl);\n> > +\n> > +\treturn 0;\n> \n> Application should call rte_eal_cleanup() before exit. Otherwise, each\n> secondary started and stopped will leak memory.\n\nOK, will add it.\n\nThanks\nQi\n\n> \n> --\n> Thanks,\n> Anatoly", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 6FFD61BB27;\n\tFri, 22 Jun 2018 08:50:06 +0200 (CEST)", "from mga18.intel.com (mga18.intel.com [134.134.136.126])\n\tby dpdk.org (Postfix) with ESMTP id CCAAB1BB20\n\tfor <dev@dpdk.org>; Fri, 22 Jun 2018 08:50:02 +0200 (CEST)", "from fmsmga004.fm.intel.com ([10.253.24.48])\n\tby orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t21 Jun 2018 23:50:00 -0700", "from fmsmsx103.amr.corp.intel.com ([10.18.124.201])\n\tby fmsmga004.fm.intel.com with ESMTP; 21 Jun 2018 23:50:00 -0700", "from fmsmsx123.amr.corp.intel.com (10.18.125.38) by\n\tFMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Thu, 21 Jun 2018 23:50:00 -0700", "from shsmsx101.ccr.corp.intel.com (10.239.4.153) by\n\tfmsmsx123.amr.corp.intel.com (10.18.125.38) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Thu, 21 Jun 2018 23:50:00 -0700", "from shsmsx103.ccr.corp.intel.com ([169.254.4.51]) by\n\tSHSMSX101.ccr.corp.intel.com ([169.254.1.82]) with mapi id\n\t14.03.0319.002; Fri, 22 Jun 2018 14:49:57 +0800" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.51,255,1526367600\"; d=\"scan'208\";a=\"65365548\"", "From": "\"Zhang, Qi Z\" <qi.z.zhang@intel.com>", "To": "\"Burakov, Anatoly\" <anatoly.burakov@intel.com>, \"thomas@monjalon.net\"\n\t<thomas@monjalon.net>", "CC": "\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>, \"dev@dpdk.org\"\n\t<dev@dpdk.org>, \"Richardson, Bruce\" <bruce.richardson@intel.com>,\n\t\"Yigit, Ferruh\" <ferruh.yigit@intel.com>, \"Shelton, Benjamin H\"\n\t<benjamin.h.shelton@intel.com>, \"Vangati, Narender\"\n\t<narender.vangati@intel.com>", "Thread-Topic": "[PATCH 22/22] examples/devmgm_mp: add simple device management\n\tsample", "Thread-Index": "AQHUBvAyXmRIyvxYF0Cx4z3UXggCAqRr2Mgw", "Date": "Fri, 22 Jun 2018 06:49:56 +0000", "Message-ID": "<039ED4275CED7440929022BC67E706115323B90F@SHSMSX103.ccr.corp.intel.com>", "References": "<20180607123849.14439-1-qi.z.zhang@intel.com>\n\t<20180607123849.14439-23-qi.z.zhang@intel.com>\n\t<181b45a2-93cc-5700-5f9e-2dfdf474e38c@intel.com>", "In-Reply-To": "<181b45a2-93cc-5700-5f9e-2dfdf474e38c@intel.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-titus-metadata-40": "eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZmM5Y2FlZDctODFlZS00NjQ0LWE1YmQtYjQzMjFlZmVkNzllIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiOElpeDVLYkE0QWhPa29JSis5K0JCelwvNkt6YWU5OTlcL2IrY1J3UFhqS0NXZ2pHczZaYnBlMTdaNWttN3Nha2VwIn0=", "x-ctpclassification": "CTP_NT", "dlp-product": "dlpe-windows", "dlp-version": "11.0.200.100", "dlp-reaction": "no-action", "x-originating-ip": "[10.239.127.40]", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "MIME-Version": "1.0", "Subject": "Re: [dpdk-dev] [PATCH 22/22] examples/devmgm_mp: add simple device\n\tmanagement sample", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null } ]