Patch Comment List
List patch comments
GET /api/patches/40748/comments/?format=api
[ { "id": 82267, "web_url": "http://patches.dpdk.org/comment/82267/", "msgid": "<cf377323-2cb4-72c2-c8ef-42f438adc805@intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/cf377323-2cb4-72c2-c8ef-42f438adc805@intel.com", "date": "2018-06-15T15:44:43", "subject": "Re: [dpdk-dev] [PATCH 04/22] ethdev: enable hotplug on multi-process", "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 patch introduce the solution to handle different hotplug cases in\n> multi-process situation, it include below scenario:\n> \n> 1. Attach a share device from primary\n> 2. Detach a share device from primary\n> 3. Attach a share device from secondary\n> 4. Detach a share device from secondary\n> 5. Attach a private device from secondary\n> 6. Detach a private device from secondary\n> 7. Detach a share device from secondary privately\n> 8. Attach a share device from secondary privately\n> \n> In primary-secondary process model, we assume device is shared by default.\n> that means attach or detach a device on any process will broadcast to\n> all other processes through mp channel then device information will be\n> synchronized on all processes.\n> \n> Any failure during attaching process will cause inconsistent status\n> between processes, so proper rollback action should be considered.\n> Also it is not safe to detach a share device when other process still use\n> it, so a handshake mechanism is introduced, it will be implemented in\n> following separate patch.\n> \n> Scenario for Case 1, 2:\n> \n> attach device\n> a) primary attach the new device if failed goto h).\n> b) primary send attach sync request to all secondary.\n> c) secondary receive request and attach device and send reply.\n> d) primary check the reply if all success go to i).\n> e) primary send attach rollback sync request to all secondary.\n> f) secondary receive the request and detach device and send reply.\n> g) primary receive the reply and detach device as rollback action.\n> h) attach fail\n> i) attach success\n> \n> detach device\n> a) primary perform pre-detach check, if device is locked, goto i).\n> b) primary send pre-detach sync request to all secondary.\n> c) secondary perform pre-detach check and send reply.\n> d) primary check the reply if any fail goto i).\n> e) primary send detach sync request to all secondary\n> f) secondary detach the device and send reply (assume no fail)\n> g) primary detach the device.\n> h) detach success\n> i) detach failed\n> \n> Case 3, 4:\n> This will be implemented in following patch.\n> \n> Case 5, 6:\n> Secondary process can attach private device which only visible to itself,\n> in this case no IPC is involved, primary process is not allowd to have\n> private device so far.\n> \n> Case 7, 8:\n> Secondary process can also temporally to detach a share device \"privately\"\n> then attach it back later, this action also not impact other processes.\n> \n> APIs chenages:\n> \n> rte_eth_dev_attach and rte_eth_dev_attach are extended to support\n> share device attach/detach in primary-secondary process model, it will\n> be called in case 1,2,3,4.\n> \n> New API rte_eth_dev_attach_private and rte_eth_dev_detach_private are\n> introduced to cover case 5,6,7,8, this API can only be invoked in secondary\n> process.\n> \n> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>\n> ---\n> lib/librte_eal/common/eal_private.h | 8 ++\n> lib/librte_eal/linuxapp/eal/eal.c | 6 ++\n> lib/librte_ethdev/Makefile | 1 +\n> lib/librte_ethdev/rte_ethdev.c | 183 ++++++++++++++++++++++++++++---\n> lib/librte_ethdev/rte_ethdev.h | 37 +++++++\n> lib/librte_ethdev/rte_ethdev_core.h | 5 +\n> lib/librte_ethdev/rte_ethdev_driver.h | 27 +++++\n> lib/librte_ethdev/rte_ethdev_mp.c | 195 ++++++++++++++++++++++++++++++++++\n> lib/librte_ethdev/rte_ethdev_mp.h | 44 ++++++++\n> 9 files changed, 489 insertions(+), 17 deletions(-)\n> create mode 100644 lib/librte_ethdev/rte_ethdev_mp.c\n> create mode 100644 lib/librte_ethdev/rte_ethdev_mp.h\n> \n\nHaven't looked at the code yet, but general comment: please don't prefix \ninternal-only files with rte_, it makes it look like they are part of \nexternal API.", "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 C28651BF14;\n\tFri, 15 Jun 2018 17:44:49 +0200 (CEST)", "from mga07.intel.com (mga07.intel.com [134.134.136.100])\n\tby dpdk.org (Postfix) with ESMTP id F0BD91BF13\n\tfor <dev@dpdk.org>; Fri, 15 Jun 2018 17:44:47 +0200 (CEST)", "from fmsmga003.fm.intel.com ([10.253.24.29])\n\tby orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t15 Jun 2018 08:44:46 -0700", "from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.66])\n\t([10.237.220.66])\n\tby FMSMGA003.fm.intel.com with ESMTP; 15 Jun 2018 08:44:44 -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,227,1526367600\"; d=\"scan'208\";a=\"57630472\"", "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-5-qi.z.zhang@intel.com>", "From": "\"Burakov, Anatoly\" <anatoly.burakov@intel.com>", "Message-ID": "<cf377323-2cb4-72c2-c8ef-42f438adc805@intel.com>", "Date": "Fri, 15 Jun 2018 16:44:43 +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-5-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 04/22] ethdev: enable hotplug on multi-process", "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://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://dpdk.org/ml/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://dpdk.org/ml/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": 82319, "web_url": "http://patches.dpdk.org/comment/82319/", "msgid": "<3c273e40-9954-e9a3-2c78-9e245bacc19d@intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/3c273e40-9954-e9a3-2c78-9e245bacc19d@intel.com", "date": "2018-06-18T08:18:17", "subject": "Re: [dpdk-dev] [PATCH 04/22] ethdev: enable hotplug on multi-process", "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 patch introduce the solution to handle different hotplug cases in\n> multi-process situation, it include below scenario:\n> \n> 1. Attach a share device from primary\n> 2. Detach a share device from primary\n> 3. Attach a share device from secondary\n> 4. Detach a share device from secondary\n> 5. Attach a private device from secondary\n> 6. Detach a private device from secondary\n> 7. Detach a share device from secondary privately\n> 8. Attach a share device from secondary privately\n> \n> In primary-secondary process model, we assume device is shared by default.\n> that means attach or detach a device on any process will broadcast to\n> all other processes through mp channel then device information will be\n> synchronized on all processes.\n> \n> Any failure during attaching process will cause inconsistent status\n> between processes, so proper rollback action should be considered.\n> Also it is not safe to detach a share device when other process still use\n> it, so a handshake mechanism is introduced, it will be implemented in\n> following separate patch.\n> \n> Scenario for Case 1, 2:\n> \n> attach device\n> a) primary attach the new device if failed goto h).\n> b) primary send attach sync request to all secondary.\n> c) secondary receive request and attach device and send reply.\n> d) primary check the reply if all success go to i).\n> e) primary send attach rollback sync request to all secondary.\n> f) secondary receive the request and detach device and send reply.\n> g) primary receive the reply and detach device as rollback action.\n> h) attach fail\n> i) attach success\n> \n> detach device\n> a) primary perform pre-detach check, if device is locked, goto i).\n> b) primary send pre-detach sync request to all secondary.\n> c) secondary perform pre-detach check and send reply.\n> d) primary check the reply if any fail goto i).\n> e) primary send detach sync request to all secondary\n> f) secondary detach the device and send reply (assume no fail)\n> g) primary detach the device.\n> h) detach success\n> i) detach failed\n> \n> Case 3, 4:\n> This will be implemented in following patch.\n\nIf these will be implemented in following patch, why spend half the \ncommit message talking about it? :) This commit doesn't implement \nsecondary process functionality at all, so the commit message should \nprobably be reworded to only include primary process logic, no?\n\n> \n> Case 5, 6:\n> Secondary process can attach private device which only visible to itself,\n> in this case no IPC is involved, primary process is not allowd to have\n> private device so far.\n> \n> Case 7, 8:\n> Secondary process can also temporally to detach a share device \"privately\"\n> then attach it back later, this action also not impact other processes.\n> \n> APIs chenages:\n\nMultiple typos - \"chenages\", \"temporally\", \"allowd\", etc.\n\n> \n> rte_eth_dev_attach and rte_eth_dev_attach are extended to support\n> share device attach/detach in primary-secondary process model, it will\n> be called in case 1,2,3,4.\n> \n> New API rte_eth_dev_attach_private and rte_eth_dev_detach_private are\n> introduced to cover case 5,6,7,8, this API can only be invoked in secondary\n> process.\n> > Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>\n> ---\n\n<snip>\n\n> \trte_eal_mcfg_complete();\n> \n> +\tif (rte_eth_dev_mp_init()) {\n> +\t\trte_eal_init_alert(\"rte_eth_dev_mp_init() failed\\n\");\n> +\t\trte_errno = ENOEXEC;\n> +\t\treturn -1;\n> +\t}\n> +\n\nWhy is this done after the end of init? rte_eal_mcfg_complete() makes it \nso that secondaries can initialize, at that point all initialization \nshould have been finished. I would expect this to be called after \n(before?) bus probe, since this is device-related.\n\n> \treturn fctret;\n> }\n> \n> diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile\n> index c2f2f7d82..04e93f337 100644\n> --- a/lib/librte_ethdev/Makefile\n> +++ b/lib/librte_ethdev/Makefile\n> @@ -19,6 +19,7 @@ EXPORT_MAP := rte_ethdev_version.map\n> LIBABIVER := 9\n> \n\n<snip>\n\n> +\tif (rte_eal_process_type() != RTE_PROC_PRIMARY) {\n> +\n> +\t\t/**\n> +\t\t * If secondary process, we just send request to primray\n> +\t\t * to start the process.\n> +\t\t */\n> +\t\treq.t = REQ_TYPE_ATTACH;\n> +\t\tstrlcpy(req.devargs, devargs, MAX_DEV_ARGS_LEN);\n> +\n> +\t\tret = rte_eth_dev_request_to_primary(&req);\n> +\t\tif (ret) {\n> +\t\t\tethdev_log(ERR, \"Failed to send device attach request to primary\\n\");\n\nThe log message is a little misleading. It can be that secondary has \nfailed to send request. It can also be that it succeeded, but the attach \nitself has failed. I think a better message would be \"attach request has \nfailed\" or something to that effect.\n\n> +\t\t\treturn ret;\n> +\t\t}\n> +\n> +\t\t*port_id = req.port_id;\n> +\t\treturn req.result;\n> +\t}\n> +\n> +\tret = do_eth_dev_attach(devargs, port_id);\n> +\tif (ret)\n> +\t\treturn ret;\n> +\n> +\t/* send attach request to seoncary */\n> +\treq.t = REQ_TYPE_ATTACH;\n> +\tstrlcpy(req.devargs, devargs, MAX_DEV_ARGS_LEN);\n> +\treq.port_id = *port_id;\n> +\tret = rte_eth_dev_request_to_secondary(&req);\n> +\tif (ret) {\n> +\t\tethdev_log(ERR, \"Failed to send device attach request to secondary\\n\");\n\nSame as above - log message can/might be misleading. There are a few \nother places where similar log message is present, those should be \ncorrected too.\n\n> +\t\tgoto rollback;\n> +\t}\n> +\n> +\tif (req.result)\n> +\t\tgoto rollback;\n> +\n> +\treturn 0;\n\n<snip>\n\n> +{\n> +\tuint32_t dev_flags;\n> +\n> +\tif (rte_eal_process_type() == RTE_PROC_PRIMARY)\n> +\t\treturn -ENOTSUP;\n> +\n> +\tRTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);\n> +\n> +\tdev_flags = rte_eth_devices[port_id].data->dev_flags;\n> +\tif (dev_flags & RTE_ETH_DEV_BONDED_SLAVE) {\n> +\t\tethdev_log(ERR,\n> +\t\t\t\"Port %\" PRIu16 \" is bonded, cannot detach\", port_id);\n> +\t\treturn -ENOTSUP;\n> +\t}\n\nDo we have to do a similar check for failsafe devices?\n\n> +\n> +\treturn do_eth_dev_detach(port_id);\n> +}\n> +\n> static int\n> rte_eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)\n> {\n> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h\n> index 36e3984ea..bb03d613b 100644\n> --- a/lib/librte_ethdev/rte_ethdev.h\n> +++ b/lib/librte_ethdev/rte_ethdev.h\n\n<snip>\n\n> /**\n> + * Attach a private Ethernet device specified by arguments.\n> + * A private device is invisible to other process.\n> + * Can only be invoked in secondary process.\n> + *\n> + * @param devargs\n> + * A pointer to a strings array describing the new device\n> + * to be attached. The strings should be a pci address like\n> + * '0000:01:00.0' or virtual device name like 'net_pcap0'.\n> + * @param port_id\n> + * A pointer to a port identifier actually attached.\n> + * @return\n> + * 0 on success and port_id is filled, negative on error\n> + */\n> +int rte_eth_dev_attach_private(const char *devargs, uint16_t *port_id);\n\nNew API's should be marked as __rte_experimental.\n\n> +\n> +/**\n> * Detach a Ethernet device specified by port identifier.\n> * This function must be called when the device is in the\n> * closed state.\n> + * In multi-process mode, it will sync with other process\n> + * to detach the device.\n> *\n> * @param port_id\n> * The port identifier of the device to detach.\n> @@ -1490,6 +1511,22 @@ int rte_eth_dev_attach(const char *devargs, uint16_t *port_id);\n\n<snip>\n\n> + * Detach a Ethernet device in current process.\n> + *\n> + * @param port_id\n> + * The port identifier of the device to detach.\n> + * @param devname\n> + * A pointer to a buffer that will be filled with the device name.\n> + * This buffer must be at least RTE_DEV_NAME_MAX_LEN long.\n> + * @return\n> + * 0 on success and devname is filled, negative on error\n> + */\n> +int do_eth_dev_detach(uint16_t port_id);\n> +\n\nWhy is this made part of an external API? You should have a separate, \nprivate header file for these.\n\n> #ifdef __cplusplus\n> }\n> #endif\n> diff --git a/lib/librte_ethdev/rte_ethdev_mp.c b/lib/librte_ethdev/rte_ethdev_mp.c\n> new file mode 100644\n> index 000000000..8ede8151d\n> --- /dev/null\n> +++ b/lib/librte_ethdev/rte_ethdev_mp.c\n> @@ -0,0 +1,195 @@\n> +/* SPDX-License-Identifier: BSD-3-Clause\n> + * Copyright(c) 2010-2018 Intel Corporation\n> + */\n> +\n> +#include \"rte_ethdev_driver.h\"\n> +#include \"rte_ethdev_mp.h\"\n> +\n> +static int detach_on_secondary(uint16_t port_id)\n\n<snip>\n\n> +\tfree(da.args);\n> +\treturn 0;\n> +}\n> +\n> +static int handle_secondary_request(const struct rte_mp_msg *msg, const void *peer)\n> +{\n> +\t(void)msg;\n> +\t(void)(peer);\n> +\treturn -ENOTSUP;\n\nPlease either mark arguments as __rte_unused, or use RTE_SET_USED(blah) \nmacro. Same in other similar places.\n\n> +}\n> +\n> +static int handle_primary_response(const struct rte_mp_msg *msg, const void *peer)\n> +{\n> +\t(void)msg;\n> +\t(void)(peer);\n> +\treturn -ENOTSUP;\n> +}\n> +\n> +static int handle_primary_request(const struct rte_mp_msg *msg, const void *peer)\n> +{\n> +\tconst struct eth_dev_mp_req *req =\n> +\t\t(const struct eth_dev_mp_req *)msg->param;\n\n<snip>\n\n> +\tcase REQ_TYPE_DETACH:\n> +\tcase REQ_TYPE_ATTACH_ROLLBACK:\n> +\t\tret = detach_on_secondary(req->port_id);\n> +\t\tbreak;\n> +\tdefault:\n> +\t\tret = -EINVAL;\n> +\t}\n> +\n> +\tstrcpy(mp_resp.name, ETH_DEV_MP_ACTION_REQUEST);\n\nHere and in other places: rte_strlcpy?", "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 A53129E4;\n\tMon, 18 Jun 2018 10:18:27 +0200 (CEST)", "from mga07.intel.com (mga07.intel.com [134.134.136.100])\n\tby dpdk.org (Postfix) with ESMTP id E5B3998\n\tfor <dev@dpdk.org>; Mon, 18 Jun 2018 10:18:23 +0200 (CEST)", "from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t18 Jun 2018 01:18:20 -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 01:18:18 -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=\"65005320\"", "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-5-qi.z.zhang@intel.com>", "From": "\"Burakov, Anatoly\" <anatoly.burakov@intel.com>", "Message-ID": "<3c273e40-9954-e9a3-2c78-9e245bacc19d@intel.com>", "Date": "Mon, 18 Jun 2018 09:18:17 +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-5-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 04/22] ethdev: enable hotplug on multi-process", "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": 82361, "web_url": "http://patches.dpdk.org/comment/82361/", "msgid": "<039ED4275CED7440929022BC67E7061153239FAD@SHSMSX103.ccr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/039ED4275CED7440929022BC67E7061153239FAD@SHSMSX103.ccr.corp.intel.com", "date": "2018-06-19T03:22:53", "subject": "Re: [dpdk-dev] [PATCH 04/22] ethdev: enable hotplug on multi-process", "submitter": { "id": 504, "url": "http://patches.dpdk.org/api/people/504/?format=api", "name": "Qi Zhang", "email": "qi.z.zhang@intel.com" }, "content": "> -----Original Message-----\n> From: Burakov, Anatoly\n> Sent: Monday, June 18, 2018 4:18 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 04/22] ethdev: enable hotplug on multi-process\n> \n> On 07-Jun-18 1:38 PM, Qi Zhang wrote:\n> > The patch introduce the solution to handle different hotplug cases in\n> > multi-process situation, it include below scenario:\n> >\n> > 1. Attach a share device from primary\n> > 2. Detach a share device from primary\n> > 3. Attach a share device from secondary 4. Detach a share device from\n> > secondary 5. Attach a private device from secondary 6. Detach a\n> > private device from secondary 7. Detach a share device from secondary\n> > privately 8. Attach a share device from secondary privately\n> >\n> > In primary-secondary process model, we assume device is shared by\n> default.\n> > that means attach or detach a device on any process will broadcast to\n> > all other processes through mp channel then device information will be\n> > synchronized on all processes.\n> >\n> > Any failure during attaching process will cause inconsistent status\n> > between processes, so proper rollback action should be considered.\n> > Also it is not safe to detach a share device when other process still\n> > use it, so a handshake mechanism is introduced, it will be implemented\n> > in following separate patch.\n> >\n> > Scenario for Case 1, 2:\n> >\n> > attach device\n> > a) primary attach the new device if failed goto h).\n> > b) primary send attach sync request to all secondary.\n> > c) secondary receive request and attach device and send reply.\n> > d) primary check the reply if all success go to i).\n> > e) primary send attach rollback sync request to all secondary.\n> > f) secondary receive the request and detach device and send reply.\n> > g) primary receive the reply and detach device as rollback action.\n> > h) attach fail\n> > i) attach success\n> >\n> > detach device\n> > a) primary perform pre-detach check, if device is locked, goto i).\n> > b) primary send pre-detach sync request to all secondary.\n> > c) secondary perform pre-detach check and send reply.\n> > d) primary check the reply if any fail goto i).\n> > e) primary send detach sync request to all secondary\n> > f) secondary detach the device and send reply (assume no fail)\n> > g) primary detach the device.\n> > h) detach success\n> > i) detach failed\n> >\n> > Case 3, 4:\n> > This will be implemented in following patch.\n> \n> If these will be implemented in following patch, why spend half the commit\n> message talking about it? :) \n\nSorry, I didn't get your point about \"see half commit to talk about it\" :)\nThis patch covered an overview, and also the implementation of case 1,2,5,6,7,8\n\nFor case 3, 4, just below 4 lines to describe it\n\n3. Attach a share device from secondary.\n4. Detach a share device from secondary.\nCase 3, 4:\nThis will be implemented in following patch.\n\n> is commit doesn't implement secondary\n> process functionality at all, so the commit message should probably be\n> reworded to only include primary process logic, no?\n\nOK, I will reword it to highlight the patch's scope as description at above.\n\n> \n> >\n> > Case 5, 6:\n> > Secondary process can attach private device which only visible to itself,\n> > in this case no IPC is involved, primary process is not allowed to have\n> > private device so far.\n> >\n> > Case 7, 8:\n> > Secondary process can also temporally to detach a share device \"privately\"\n> > then attach it back later, this action also not impact other processes.\n> >\n> > APIs chenages:\n> \n> Multiple typos - \"chenages\", \"temporally\", \"allowd\", etc.\n\nThanks\n\n> \n> >\n> > rte_eth_dev_attach and rte_eth_dev_attach are extended to support\n> > share device attach/detach in primary-secondary process model, it will\n> > be called in case 1,2,3,4.\n> >\n> > New API rte_eth_dev_attach_private and rte_eth_dev_detach_private are\n> > introduced to cover case 5,6,7,8, this API can only be invoked in secondary\n> > process.\n> > > Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>\n> > ---\n> \n> <snip>\n> \n> > \trte_eal_mcfg_complete();\n> >\n> > +\tif (rte_eth_dev_mp_init()) {\n> > +\t\trte_eal_init_alert(\"rte_eth_dev_mp_init() failed\\n\");\n> > +\t\trte_errno = ENOEXEC;\n> > +\t\treturn -1;\n> > +\t}\n> > +\n> \n> Why is this done after the end of init? rte_eal_mcfg_complete() makes it\n> so that secondaries can initialize, at that point all initialization\n> should have been finished. I would expect this to be called after\n> (before?) bus probe, since this is device-related.\n\nOK will move ahead.\n\n> \n> > \treturn fctret;\n> > }\n> >\n> > diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile\n> > index c2f2f7d82..04e93f337 100644\n> > --- a/lib/librte_ethdev/Makefile\n> > +++ b/lib/librte_ethdev/Makefile\n> > @@ -19,6 +19,7 @@ EXPORT_MAP := rte_ethdev_version.map\n> > LIBABIVER := 9\n> >\n> \n> <snip>\n> \n> > +\tif (rte_eal_process_type() != RTE_PROC_PRIMARY) {\n> > +\n> > +\t\t/**\n> > +\t\t * If secondary process, we just send request to primray\n> > +\t\t * to start the process.\n> > +\t\t */\n> > +\t\treq.t = REQ_TYPE_ATTACH;\n> > +\t\tstrlcpy(req.devargs, devargs, MAX_DEV_ARGS_LEN);\n> > +\n> > +\t\tret = rte_eth_dev_request_to_primary(&req);\n> > +\t\tif (ret) {\n> > +\t\t\tethdev_log(ERR, \"Failed to send device attach request to\n> primary\\n\");\n> \n> The log message is a little misleading. It can be that secondary has\n> failed to send request. It can also be that it succeeded, but the attach\n> itself has failed. I think a better message would be \"attach request has\n> failed\" or something to that effect.\n\nThe return value of rte_eth_dev_request_to_primary only means communication fail,\n(message not able to send, or not get reply in time).\nbut not the fail on attach/detach itself. (which comes from req->result)\n\n> \n> > +\t\t\treturn ret;\n> > +\t\t}\n> > +\n> > +\t\t*port_id = req.port_id;\n> > +\t\treturn req.result;\n> > +\t}\n> > +\n> > +\tret = do_eth_dev_attach(devargs, port_id);\n> > +\tif (ret)\n> > +\t\treturn ret;\n> > +\n> > +\t/* send attach request to seoncary */\n> > +\treq.t = REQ_TYPE_ATTACH;\n> > +\tstrlcpy(req.devargs, devargs, MAX_DEV_ARGS_LEN);\n> > +\treq.port_id = *port_id;\n> > +\tret = rte_eth_dev_request_to_secondary(&req);\n> > +\tif (ret) {\n> > +\t\tethdev_log(ERR, \"Failed to send device attach request to\n> secondary\\n\");\n> \n> Same as above - log message can/might be misleading. There are a few\n> other places where similar log message is present, those should be\n> corrected too.\n\nSame as above\n\n> \n> > +\t\tgoto rollback;\n> > +\t}\n> > +\n> > +\tif (req.result)\n> > +\t\tgoto rollback;\n> > +\n> > +\treturn 0;\n> \n> <snip>\n> \n> > +{\n> > +\tuint32_t dev_flags;\n> > +\n> > +\tif (rte_eal_process_type() == RTE_PROC_PRIMARY)\n> > +\t\treturn -ENOTSUP;\n> > +\n> > +\tRTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);\n> > +\n> > +\tdev_flags = rte_eth_devices[port_id].data->dev_flags;\n> > +\tif (dev_flags & RTE_ETH_DEV_BONDED_SLAVE) {\n> > +\t\tethdev_log(ERR,\n> > +\t\t\t\"Port %\" PRIu16 \" is bonded, cannot detach\", port_id);\n> > +\t\treturn -ENOTSUP;\n> > +\t}\n> \n> Do we have to do a similar check for failsafe devices?\n\nJust keep it same logic as before, it could be a separate patch to fix I guess.\n\n> \n> > +\n> > +\treturn do_eth_dev_detach(port_id);\n> > +}\n> > +\n> > static int\n> > rte_eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t\n> nb_queues)\n> > {\n> > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h\n> > index 36e3984ea..bb03d613b 100644\n> > --- a/lib/librte_ethdev/rte_ethdev.h\n> > +++ b/lib/librte_ethdev/rte_ethdev.h\n> \n> <snip>\n> \n> > /**\n> > + * Attach a private Ethernet device specified by arguments.\n> > + * A private device is invisible to other process.\n> > + * Can only be invoked in secondary process.\n> > + *\n> > + * @param devargs\n> > + * A pointer to a strings array describing the new device\n> > + * to be attached. The strings should be a pci address like\n> > + * '0000:01:00.0' or virtual device name like 'net_pcap0'.\n> > + * @param port_id\n> > + * A pointer to a port identifier actually attached.\n> > + * @return\n> > + * 0 on success and port_id is filled, negative on error\n> > + */\n> > +int rte_eth_dev_attach_private(const char *devargs, uint16_t *port_id);\n> \n> New API's should be marked as __rte_experimental.\n\nOK\n\n> \n> > +\n> > +/**\n> > * Detach a Ethernet device specified by port identifier.\n> > * This function must be called when the device is in the\n> > * closed state.\n> > + * In multi-process mode, it will sync with other process\n> > + * to detach the device.\n> > *\n> > * @param port_id\n> > * The port identifier of the device to detach.\n> > @@ -1490,6 +1511,22 @@ int rte_eth_dev_attach(const char *devargs,\n> uint16_t *port_id);\n> \n> <snip>\n> \n> > + * Detach a Ethernet device in current process.\n> > + *\n> > + * @param port_id\n> > + * The port identifier of the device to detach.\n> > + * @param devname\n> > + * A pointer to a buffer that will be filled with the device name.\n> > + * This buffer must be at least RTE_DEV_NAME_MAX_LEN long.\n> > + * @return\n> > + * 0 on success and devname is filled, negative on error\n> > + */\n> > +int do_eth_dev_detach(uint16_t port_id);\n> > +\n> \n> Why is this made part of an external API? You should have a separate,\n> private header file for these.\n\nOK, will add to ethdev_private.h in v2.\n\n> \n> > #ifdef __cplusplus\n> > }\n> > #endif\n> > diff --git a/lib/librte_ethdev/rte_ethdev_mp.c\n> b/lib/librte_ethdev/rte_ethdev_mp.c\n> > new file mode 100644\n> > index 000000000..8ede8151d\n> > --- /dev/null\n> > +++ b/lib/librte_ethdev/rte_ethdev_mp.c\n> > @@ -0,0 +1,195 @@\n> > +/* SPDX-License-Identifier: BSD-3-Clause\n> > + * Copyright(c) 2010-2018 Intel Corporation\n> > + */\n> > +\n> > +#include \"rte_ethdev_driver.h\"\n> > +#include \"rte_ethdev_mp.h\"\n> > +\n> > +static int detach_on_secondary(uint16_t port_id)\n> \n> <snip>\n> \n> > +\tfree(da.args);\n> > +\treturn 0;\n> > +}\n> > +\n> > +static int handle_secondary_request(const struct rte_mp_msg *msg, const\n> void *peer)\n> > +{\n> > +\t(void)msg;\n> > +\t(void)(peer);\n> > +\treturn -ENOTSUP;\n> \n> Please either mark arguments as __rte_unused, or use RTE_SET_USED(blah)\n> macro. Same in other similar places.\n\nOK.\n\n> \n> > +}\n> > +\n> > +static int handle_primary_response(const struct rte_mp_msg *msg, const\n> void *peer)\n> > +{\n> > +\t(void)msg;\n> > +\t(void)(peer);\n> > +\treturn -ENOTSUP;\n> > +}\n> > +\n> > +static int handle_primary_request(const struct rte_mp_msg *msg, const\n> void *peer)\n> > +{\n> > +\tconst struct eth_dev_mp_req *req =\n> > +\t\t(const struct eth_dev_mp_req *)msg->param;\n> \n> <snip>\n> \n> > +\tcase REQ_TYPE_DETACH:\n> > +\tcase REQ_TYPE_ATTACH_ROLLBACK:\n> > +\t\tret = detach_on_secondary(req->port_id);\n> > +\t\tbreak;\n> > +\tdefault:\n> > +\t\tret = -EINVAL;\n> > +\t}\n> > +\n> > +\tstrcpy(mp_resp.name, ETH_DEV_MP_ACTION_REQUEST);\n> \n> Here and in other places: rte_strlcpy?\n\nOK\n\nThanks!\nQi\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 435139E4;\n\tTue, 19 Jun 2018 05:23:10 +0200 (CEST)", "from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby dpdk.org (Postfix) with ESMTP id 9DE791D7\n\tfor <dev@dpdk.org>; Tue, 19 Jun 2018 05:23:08 +0200 (CEST)", "from fmsmga003.fm.intel.com ([10.253.24.29])\n\tby orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t18 Jun 2018 20:23:07 -0700", "from fmsmsx104.amr.corp.intel.com ([10.18.124.202])\n\tby FMSMGA003.fm.intel.com with ESMTP; 18 Jun 2018 20:22:56 -0700", "from fmsmsx115.amr.corp.intel.com (10.18.116.19) by\n\tfmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Mon, 18 Jun 2018 20:22:56 -0700", "from shsmsx101.ccr.corp.intel.com (10.239.4.153) by\n\tfmsmsx115.amr.corp.intel.com (10.18.116.19) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Mon, 18 Jun 2018 20:22:56 -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; Tue, 19 Jun 2018 11:22:54 +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,241,1526367600\"; d=\"scan'208\";a=\"58359042\"", "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 04/22] ethdev: enable hotplug on multi-process", "Thread-Index": "AQHUBtzyoDZY11QPm0CDugZc44S6kKRm4aVQ", "Date": "Tue, 19 Jun 2018 03:22:53 +0000", "Message-ID": "<039ED4275CED7440929022BC67E7061153239FAD@SHSMSX103.ccr.corp.intel.com>", "References": "<20180607123849.14439-1-qi.z.zhang@intel.com>\n\t<20180607123849.14439-5-qi.z.zhang@intel.com>\n\t<3c273e40-9954-e9a3-2c78-9e245bacc19d@intel.com>", "In-Reply-To": "<3c273e40-9954-e9a3-2c78-9e245bacc19d@intel.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-titus-metadata-40": "eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjE4NTdmYTUtNTQ2Ny00YzdmLTk2MzItNmZmYjJkMjc1YjQyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRDJCK0Jna0NTOWthdjhyS05xUWJuOGUyZHVxR0Y3VnlyYTFBdVJIRFp2Y3hVc0lkaW4rczBEWDhWR0p1dUZSSCJ9", "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 04/22] ethdev: enable hotplug on multi-process", "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": 82370, "web_url": "http://patches.dpdk.org/comment/82370/", "msgid": "<2693ba60-83f0-7698-46b9-54e8ad2c49e3@intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/2693ba60-83f0-7698-46b9-54e8ad2c49e3@intel.com", "date": "2018-06-19T08:37:08", "subject": "Re: [dpdk-dev] [PATCH 04/22] ethdev: enable hotplug on multi-process", "submitter": { "id": 4, "url": "http://patches.dpdk.org/api/people/4/?format=api", "name": "Anatoly Burakov", "email": "anatoly.burakov@intel.com" }, "content": "On 19-Jun-18 4:22 AM, Zhang, Qi Z wrote:\n> \n> \n>> -----Original Message-----\n>> From: Burakov, Anatoly\n>> Sent: Monday, June 18, 2018 4:18 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 04/22] ethdev: enable hotplug on multi-process\n>>\n>> On 07-Jun-18 1:38 PM, Qi Zhang wrote:\n>>> The patch introduce the solution to handle different hotplug cases in\n>>> multi-process situation, it include below scenario:\n>>>\n>>> 1. Attach a share device from primary\n>>> 2. Detach a share device from primary\n>>> 3. Attach a share device from secondary 4. Detach a share device from\n>>> secondary 5. Attach a private device from secondary 6. Detach a\n>>> private device from secondary 7. Detach a share device from secondary\n>>> privately 8. Attach a share device from secondary privately\n>>>\n>>> In primary-secondary process model, we assume device is shared by\n>> default.\n>>> that means attach or detach a device on any process will broadcast to\n>>> all other processes through mp channel then device information will be\n>>> synchronized on all processes.\n>>>\n>>> Any failure during attaching process will cause inconsistent status\n>>> between processes, so proper rollback action should be considered.\n>>> Also it is not safe to detach a share device when other process still\n>>> use it, so a handshake mechanism is introduced, it will be implemented\n>>> in following separate patch.\n>>>\n>>> Scenario for Case 1, 2:\n>>>\n>>> attach device\n>>> a) primary attach the new device if failed goto h).\n>>> b) primary send attach sync request to all secondary.\n>>> c) secondary receive request and attach device and send reply.\n>>> d) primary check the reply if all success go to i).\n>>> e) primary send attach rollback sync request to all secondary.\n>>> f) secondary receive the request and detach device and send reply.\n>>> g) primary receive the reply and detach device as rollback action.\n>>> h) attach fail\n>>> i) attach success\n>>>\n>>> detach device\n>>> a) primary perform pre-detach check, if device is locked, goto i).\n>>> b) primary send pre-detach sync request to all secondary.\n>>> c) secondary perform pre-detach check and send reply.\n>>> d) primary check the reply if any fail goto i).\n>>> e) primary send detach sync request to all secondary\n>>> f) secondary detach the device and send reply (assume no fail)\n>>> g) primary detach the device.\n>>> h) detach success\n>>> i) detach failed\n>>>\n>>> Case 3, 4:\n>>> This will be implemented in following patch.\n>>\n>> If these will be implemented in following patch, why spend half the commit\n>> message talking about it? :)\n> \n> Sorry, I didn't get your point about \"see half commit to talk about it\" :)\n> This patch covered an overview, and also the implementation of case 1,2,5,6,7,8\n> \n> For case 3, 4, just below 4 lines to describe it\n> \n> 3. Attach a share device from secondary.\n> 4. Detach a share device from secondary.\n> Case 3, 4:\n> This will be implemented in following patch.\n> \n>> is commit doesn't implement secondary\n>> process functionality at all, so the commit message should probably be\n>> reworded to only include primary process logic, no?\n> \n> OK, I will reword it to highlight the patch's scope as description at above.\n\nThanks!\n\n<snip>\n\n> \n> The return value of rte_eth_dev_request_to_primary only means communication fail,\n> (message not able to send, or not get reply in time).\n> but not the fail on attach/detach itself. (which comes from req->result)\n> \n\nAh, yes, my apologies, you're right! The log message is fine then.\n\n<snip>\n\n>>\n>> Do we have to do a similar check for failsafe devices?\n> \n> Just keep it same logic as before, it could be a separate patch to fix I guess.\n\nSure.\n\n<snip>\n\n>> Here and in other places: rte_strlcpy?\n> \n> OK\n\nApologies, this should read strlcpy, not rte_strlcpy.", "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 A8EFD2BE2;\n\tTue, 19 Jun 2018 10:37:14 +0200 (CEST)", "from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby dpdk.org (Postfix) with ESMTP id 6F4AF2BDF\n\tfor <dev@dpdk.org>; Tue, 19 Jun 2018 10:37:13 +0200 (CEST)", "from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t19 Jun 2018 01:37:12 -0700", "from aburakov-mobl.ger.corp.intel.com (HELO [10.252.26.59])\n\t([10.252.26.59])\n\tby fmsmga001.fm.intel.com with ESMTP; 19 Jun 2018 01:37:09 -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,242,1526367600\"; d=\"scan'208\";a=\"65336366\"", "To": "\"Zhang, Qi Z\" <qi.z.zhang@intel.com>,\n\t\"thomas@monjalon.net\" <thomas@monjalon.net>", "Cc": "\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>, \"Richardson, Bruce\"\n\t<bruce.richardson@intel.com>, \"Yigit, Ferruh\" <ferruh.yigit@intel.com>,\n\t\"Shelton, Benjamin H\" <benjamin.h.shelton@intel.com>,\n\t\"Vangati, Narender\" <narender.vangati@intel.com>", "References": "<20180607123849.14439-1-qi.z.zhang@intel.com>\n\t<20180607123849.14439-5-qi.z.zhang@intel.com>\n\t<3c273e40-9954-e9a3-2c78-9e245bacc19d@intel.com>\n\t<039ED4275CED7440929022BC67E7061153239FAD@SHSMSX103.ccr.corp.intel.com>", "From": "\"Burakov, Anatoly\" <anatoly.burakov@intel.com>", "Message-ID": "<2693ba60-83f0-7698-46b9-54e8ad2c49e3@intel.com>", "Date": "Tue, 19 Jun 2018 09:37:08 +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": "<039ED4275CED7440929022BC67E7061153239FAD@SHSMSX103.ccr.corp.intel.com>", "Content-Type": "text/plain; charset=utf-8; format=flowed", "Content-Language": "en-US", "Content-Transfer-Encoding": "7bit", "Subject": "Re: [dpdk-dev] [PATCH 04/22] ethdev: enable hotplug on multi-process", "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 } ]