From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70071.outbound.protection.outlook.com [40.107.7.71]) by dpdk.org (Postfix) with ESMTP id ADB675F17 for ; Mon, 9 Jul 2018 12:01:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8oR2DjfkRoKgNmn1V8jUVa1LSb4oshm8rfvrmlLYVw4=; b=hfULPnX4hjn3Vk/xR1efovwfdVlJBgd7vLMdp/YJsKQCu3l2toMiRYsDOvhHWCajyyanc730QxScIF5UbH7/Fk7y4DV+iaSvf4eI5QC5HhOo2v2EiyO1+Jh7546Ma6GC+MZ2F0Ekqgo4IZoWJZ0JUcJtM1FAh2JZKnMYeroJjLk= Received: from VI1PR0501MB2608.eurprd05.prod.outlook.com (10.168.137.20) by VI1PR0501MB2686.eurprd05.prod.outlook.com (10.172.15.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.19; Mon, 9 Jul 2018 10:01:31 +0000 Received: from VI1PR0501MB2608.eurprd05.prod.outlook.com ([fe80::9dd0:9bdb:fd59:b615]) by VI1PR0501MB2608.eurprd05.prod.outlook.com ([fe80::9dd0:9bdb:fd59:b615%7]) with mapi id 15.20.0930.022; Mon, 9 Jul 2018 10:01:31 +0000 From: Matan Azrad To: Jeff Guo , "Lu, Wenzhuo" , "stephen@networkplumber.org" , "Richardson, Bruce" , "Yigit, Ferruh" , "Ananyev, Konstantin" , "gaetan.rivet@6wind.com" , "Wu, Jingjing" , Thomas Monjalon , Mordechay Haimovsky , "Van Haaren, Harry" , "Zhang, Qi Z" , "He, Shaopeng" , "Iremonger, Bernard" , "arybchenko@solarflare.com" CC: "jblunck@infradead.org" , "shreyansh.jain@nxp.com" , "dev@dpdk.org" , "Zhang, Helin" Thread-Topic: [dpdk-dev] [PATCH v2 1/3] net/ixgbe: enable hotplug detect in ixgbe Thread-Index: AQHUF1JdauwTfrLdNEKcg7SSu6NeeKSGgOKAgAACu6CAABN1AIAAAKQAgAAPUwCAAAGYYA== Date: Mon, 9 Jul 2018 10:01:31 +0000 Message-ID: References: <1530787185-5915-1-git-send-email-jia.guo@intel.com> <1531119413-17298-1-git-send-email-jia.guo@intel.com> <1531119413-17298-2-git-send-email-jia.guo@intel.com> <6A0DE07E22DDAD4C9103DF62FEBC09093B800FC5@shsmsx102.ccr.corp.intel.com> <7b8ec59a-a52b-91b3-4c68-dc8cc7f66eb2@intel.com> In-Reply-To: <7b8ec59a-a52b-91b3-4c68-dc8cc7f66eb2@intel.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0501MB2686; 7:iqMXWxlE/NCKo+h279eGfOR5boaI1IOh/IEEk3XnhuLhXW3yRtWPZh81zRfv2ajUwjduasbdIHansE9IDlp27Sx9rdRPA53VXO8fx80xnlwVh2g4cEvvX8GG1rKuik/k+IYD0IO96RKJh43nKYJPhl76XEAh6xa9oF1Lo37kNSyMO3IoxURwHKTZzhA/CnW9YYu/CEeutvDar7lThbac2zdZOGBpSLyrqdkCw+pYQlN2/vuvnZNDvHfePKVvSvqp x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d3fdae96-7d1c-408b-abad-08d5e582f262 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0501MB2686; x-ms-traffictypediagnostic: VI1PR0501MB2686: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(185117386973197)(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0501MB2686; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0501MB2686; x-forefront-prvs: 07283408BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(366004)(396003)(136003)(39860400002)(346002)(376002)(13464003)(189003)(199004)(305945005)(68736007)(97736004)(55016002)(6436002)(9686003)(2900100001)(486006)(7416002)(2906002)(33656002)(11346002)(53936002)(229853002)(476003)(5660300001)(86362001)(7736002)(93886005)(6116002)(3846002)(74316002)(105586002)(8676002)(8936002)(81166006)(81156014)(7696005)(14454004)(6506007)(53546011)(54906003)(4326008)(25786009)(102836004)(26005)(316002)(99286004)(14444005)(256004)(5250100002)(2501003)(446003)(66066001)(186003)(110136005)(478600001)(106356001)(76176011)(6246003)(921003)(1121003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0501MB2686; H:VI1PR0501MB2608.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: npsyTsgBqicm9jG7g9HZMz+UcIcJs2XOJCd8iZN6h1cfwJPquD3TZSyn8T4RAKaDeo7JpEk6ZSTi9ZpphjUqAziBRN6/x9cXenIPzIw/vYI9mvzbWifRs2GLAzGyjjOMqiY9DCgzCPu5dMavwzKfvOXOp/hMB1ri/rvkc69ArBtkgXQOdY8qPdcUEo8GsMEl7oSX/Rt+XWRsnfbqlIAouBtSG9/D5513sEJjj7Yo1OlNh68yYzo2+Et1xWfpGap5KqSwiLHzrofRPIig+NY+0ntRkKOX/BzBubbxw8DyEkKxD6CLRP9/lI6Qn0R7c31OdsP42alWkOUc2Qp7/BUu7OdFgkrUckeF5UEfiIUxvQY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: d3fdae96-7d1c-408b-abad-08d5e582f262 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2018 10:01:31.7114 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0501MB2686 Subject: Re: [dpdk-dev] [PATCH v2 1/3] net/ixgbe: enable hotplug detect in ixgbe X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 10:01:35 -0000 Hi From: Jeff Guo > On 7/9/2018 5:04 PM, Matan Azrad wrote: > > Hi > > > > From: Jeff Guo > >> hi, wenzhuo and matan. > >> > >> > >> On 7/9/2018 3:51 PM, Matan Azrad wrote: > >>> Hi > >>> > >>> From: Lu, Wenzhuo > >>>> Hi Jeff, > >>>> > >>>>> -----Original Message----- > >>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jeff Guo > >>>>> Sent: Monday, July 9, 2018 2:57 PM > >>>>> To: stephen@networkplumber.org; Richardson, Bruce > >>>>> ; Yigit, Ferruh > >>>>> ; Ananyev, Konstantin > >>>>> ; gaetan.rivet@6wind.com; Wu, > >> Jingjing > >>>>> ; thomas@monjalon.net; > >> motih@mellanox.com; > >>>>> matan@mellanox.com; > >>>> Van > >>>>> Haaren, Harry ; Zhang, Qi Z > >>>>> ; He, Shaopeng ; > >>>>> Iremonger, Bernard ; > >>>>> arybchenko@solarflare.com > >>>>> Cc: jblunck@infradead.org; shreyansh.jain@nxp.com; dev@dpdk.org; > >>>>> Guo, Jia ; Zhang, Helin > >>>>> Subject: [dpdk-dev] [PATCH v2 1/3] net/ixgbe: enable hotplug > >>>>> detect in ixgbe > >>>>> > >>>>> This patch aim to enable hotplug detect in ixgbe pmd driver. > >>>>> Firstly it set the flags RTE_PCI_DRV_INTR_RMV in drv_flags to > >>>>> announce the hotplug ability, and then use > >>>>> rte_dev_event_callback_register to register the hotplug event > >>>>> callback to eal. When eal detect the hotplug event, it will call > >>>>> the callback to process it, if the event is hotplug remove, it > >>>>> will trigger the RTE_ETH_EVENT_INTR_RMV event into ethdev > callback to let app process the hotplug for the ethdev. > >>>>> > >>>>> This is an example for other driver, that if any driver support > >>>>> hotplug feature could be use this way to enable hotplug detect. > >>>>> > >>>>> Signed-off-by: Jeff Guo > >>>>> --- > >>>>> v2->v1: > >>>>> refine some doc. > >>>>> --- > >>>>> drivers/net/ixgbe/ixgbe_ethdev.c | 46 > >>>>> +++++++++++++++++++++++++++++++++++++++- > >>>>> 1 file changed, 45 insertions(+), 1 deletion(-) > >>>>> > >>>>> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c > >>>>> b/drivers/net/ixgbe/ixgbe_ethdev.c > >>>>> index 87d2ad0..83ce026 100644 > >>>>> --- a/drivers/net/ixgbe/ixgbe_ethdev.c > >>>>> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > >>>>> @@ -1534,6 +1534,47 @@ generate_random_mac_addr(struct > >> ether_addr > >>>>> *mac_addr) > >>>>> memcpy(&mac_addr->addr_bytes[3], &random, 3); } > >>>>> > >>>>> +static void > >>>>> +eth_dev_event_callback(char *device_name, enum > >> rte_dev_event_type > >>>>> type, > >>>>> + __rte_unused void *arg) > >>>>> +{ > >>>>> + uint32_t pid; > >>>>> + > >>>>> + if (type >=3D RTE_DEV_EVENT_MAX) { > >>>>> + fprintf(stderr, "%s called upon invalid event %d\n", > >>>>> + __func__, type); > >>>>> + fflush(stderr); > >>>>> + } > >>>>> + > >>>>> + switch (type) { > >>>>> + case RTE_DEV_EVENT_REMOVE: > >>>>> + PMD_DRV_LOG(INFO, "The device: %s has been > >>>> removed!\n", > >>>>> + device_name); > >>>>> + > >>>>> + if (!device_name) > >>>>> + return; > >>>>> + > >>>>> + for (pid =3D 0; pid < RTE_MAX_ETHPORTS; pid++) { > >>>>> + if (rte_eth_devices[pid].device) { > >>>>> + if (!strcmp(device_name, > >>>>> + rte_eth_devices[pid].device- > >name)) { > >>>>> + > _rte_eth_dev_callback_process( > >>>>> + > &rte_eth_devices[pid], > >>>>> + > RTE_ETH_EVENT_INTR_RMV, > >>>>> NULL); > >>>>> + continue; > >>>>> + } > >>>>> + } > >>>>> + } > >>>>> + break; > >>>>> + case RTE_DEV_EVENT_ADD: > >>>>> + RTE_LOG(INFO, EAL, "The device: %s has been > added!\n", > >>>>> + device_name); > >>>>> + break; > >>>>> + default: > >>>>> + break; > >>>>> + } > >>>>> +} > >>>> I don't get the point. Looks like this's a very common rte code. > >>>> Why is it put in ixgbe pmd? > >>> Jeff needs to detect if the removed device is related to this PMD, > >>> than to > >> raise RMV events for all this PMD ethdev associated ports. > >>> He should not raise RMV events for other PMD ports. > >>> > >> It should be like wenzhuo said that i could no strong reason to let > >> common way in ixgbe pmd. And sure raise RMV events for none related > >> PMD ports is not my hope. > >> Will plan to let it go into the eth dev layer to process it. > >> > > How can you run ethdev function from EAL context? > > How can the ethdev layer know which ports are related to the EAL device > removal? > > How can ethdev layer know if the port supports removal? >=20 > i mean that still let driver manage the callback , just let the common et= hdev > functional in ethdev layer. > It just define "rte_eth_dev_event_callback" in ethdev layer, and register= the > common ethdev callback in pmd driver as bellow. the eth_dev could be pass > by the whole process. >=20 > rte_dev_event_callback_register(eth_dev->device->name, > rte_eth_dev_event_callback, > (void *)eth_dev); >=20 Sorry, but I don't understand, can you explain step by step the notificatio= n path?