From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0089.outbound.protection.outlook.com [104.47.2.89]) by dpdk.org (Postfix) with ESMTP id 56B692A66 for ; Thu, 3 May 2018 13:28:00 +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; bh=+g3GWbquNTp2oTY/LZnEBy21eKxEkXREFa0RxWf+msg=; b=NbpLWTyo774JpdedMvD03ElcxcWsJR2jMAMBtrqmnLSjt4rNlZ0jLGke4EmNkjuSIjDRyABK+EsdPeTm4/ZzSWF85l2MytBXbIARS6izEotJEPABSFKSTDIAeWDRmbDg9V4AdZNclq4H814/qugooceAJkrBEswA0UL6KfldD6U= Received: from AM4PR0501MB2657.eurprd05.prod.outlook.com (10.172.215.19) by AM4PR0501MB2179.eurprd05.prod.outlook.com (10.165.82.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.735.16; Thu, 3 May 2018 11:27:57 +0000 Received: from AM4PR0501MB2657.eurprd05.prod.outlook.com ([fe80::60c2:4238:d5c3:ac46]) by AM4PR0501MB2657.eurprd05.prod.outlook.com ([fe80::60c2:4238:d5c3:ac46%10]) with mapi id 15.20.0735.016; Thu, 3 May 2018 11:27:57 +0000 From: Matan Azrad To: "Guo, Jia" , "stephen@networkplumber.org" , "bruce.richardson@intel.com" , "ferruh.yigit@intel.com" , "konstantin.ananyev@intel.com" , "gaetan.rivet@6wind.com" , "jingjing.wu@intel.com" , Thomas Monjalon , Mordechay Haimovsky , "harry.van.haaren@intel.com" , "jianfeng.tan@intel.com" CC: "jblunck@infradead.org" , "shreyansh.jain@nxp.com" , "dev@dpdk.org" , "helin.zhang@intel.com" Thread-Topic: [PATCH V20 4/4] app/testpmd: show example to handler hot unplug Thread-Index: AQHT1xq0jeUHyU30VESlBVYGqb+wqqQdobswgAA0T4CAABFWkA== Date: Thu, 3 May 2018 11:27:57 +0000 Message-ID: References: <1498711073-42917-1-git-send-email-jia.guo@intel.com> <1524058689-4954-1-git-send-email-jia.guo@intel.com> <1524058689-4954-5-git-send-email-jia.guo@intel.com> <02948416-4643-729e-2fdf-24c8d1aa6dc5@intel.com> In-Reply-To: <02948416-4643-729e-2fdf-24c8d1aa6dc5@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; AM4PR0501MB2179; 7:od/NFmQRWUmu7oAWGhceHtm0LvFjp2ZoNzlFJNlgUODWyHzgcy7xt+apidG1M5vGyAz3CLjbULEzxeqZ96p3I5E+Gsf3ADmyRaTKN3oMgxZZDreO85vKVqrFn4jKcc8S6066C0ywS/hq6AT7Y1ynhAt18aaAIldMbgYi8TYsJuE+DsQz+1wsF5+NwuodTcwaSVnJmVNaC9/OiwQv+WHQCNMHGmkVnUWbHwrl3P6cCiWkCTYeSDnsCs1Ytx1sw2TO x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM4PR0501MB2179; x-ms-traffictypediagnostic: AM4PR0501MB2179: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:AM4PR0501MB2179; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0501MB2179; x-forefront-prvs: 066153096A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(39860400002)(396003)(346002)(376002)(189003)(199004)(97736004)(6246003)(102836004)(86362001)(66066001)(7736002)(2906002)(25786009)(55016002)(4326008)(7416002)(305945005)(8676002)(81166006)(2501003)(8656006)(5660300001)(93886005)(3280700002)(106356001)(14454004)(26005)(105586002)(81156014)(3660700001)(6436002)(74316002)(2201001)(99286004)(5250100002)(478600001)(476003)(7696005)(53546011)(486006)(2900100001)(68736007)(8936002)(76176011)(229853002)(9686003)(316002)(110136005)(6116002)(3846002)(186003)(54906003)(53936002)(33656002)(59450400001)(11346002)(446003)(6506007)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0501MB2179; H:AM4PR0501MB2657.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: G5/rUT0X7DefsvGIYQ4EfDQJGkYaNl1V1e4a//K1WFMPaLn077Ja907s6gQlnIhVadCq4Np5umbkWNhxzG/yC8PoOi4BZD/GUvATaS/+wzF/hObANHoIuXoJu4gaJb3/gEEm4z03ra0Yc61/0Cg31CvUvKoJkRxFGGO41qdBo6WLRsGxxaG6HNOfRKqnl1tD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 14a60c58-861b-4b30-bb37-08d5b0e8ebd8 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14a60c58-861b-4b30-bb37-08d5b0e8ebd8 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2018 11:27:57.6972 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0501MB2179 Subject: Re: [dpdk-dev] [PATCH V20 4/4] app/testpmd: show example to handler hot unplug 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: Thu, 03 May 2018 11:28:00 -0000 Hi Guo From: Guo, Jia, Thursday, May 3, 2018 12:36 PM > hi, matan >=20 >=20 > On 5/3/2018 3:25 PM, Matan Azrad wrote: > > Hi Jeff > > > >> From: Jeff Guo, Wednesday, April 18, 2018 4:38 PM Use testpmd for > >> example, to show how an application smoothly handle failure when > >> device being hot unplug. Once app detect the removal event, the > >> callback would be called, it first stop the packet forwarding, then > >> stop the port, close the port and finally detach the port. > >> > >> Signed-off-by: Jeff Guo > >> --- > >> v20->v19: > >> remove the auto binding example. > >> --- > >> app/test-pmd/testpmd.c | 29 +++++++++++++++++++++++++---- > >> 1 file changed, 25 insertions(+), 4 deletions(-) > >> > >> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index > >> 5986ff7..3751901 100644 > >> --- a/app/test-pmd/testpmd.c > >> +++ b/app/test-pmd/testpmd.c > >> @@ -1125,6 +1125,9 @@ run_pkt_fwd_on_lcore(struct fwd_lcore *fc, > >> packet_fwd_t pkt_fwd) > >> tics_datum =3D rte_rdtsc(); > >> tics_per_1sec =3D rte_get_timer_hz(); > >> #endif > >> + if (hot_plug) > >> + rte_dev_handle_hot_unplug(); > >> + > > Again, I don't understand why the application should configure it - it > > already started the hot-plug, Can't the EAL handle this automatically w= hen > the user starts the hot-plug? > please check v21, agree with you and have already modify it. Looks good, thanks. > >> fsm =3D &fwd_streams[fc->stream_idx]; > >> nb_fs =3D fc->stream_nb; > >> do { > >> @@ -2069,6 +2072,26 @@ rmv_event_callback(void *arg) > >> dev->device->name); > >> } > >> > >> +static void > >> +rmv_dev_event_callback(char *dev_name) { > >> + uint16_t port_id; > >> + int ret; > >> + > >> + ret =3D rte_eth_dev_get_port_by_name(dev_name, &port_id); > >> + if (ret) { > >> + printf("can not get port by device %s!\n", dev_name); > >> + return; > >> + } > >> + > >> + RTE_ETH_VALID_PORTID_OR_RET(port_id); > >> + printf("removing port id:%u\n", port_id); > >> + stop_packet_forwarding(); > >> + stop_port(port_id); > >> + close_port(port_id); > >> + detach_port(port_id); > >> +} > > We have also the rmv_event_callback() which is triggered by a RMV > interrupt and running by the host thread. > > What is the context thread of rmv_dev_event_callback()? > > Shouldn't they be synchronized? Should we need both in the same time? > the context thread is interrupt thread. and we might be discuss how to s= ync > it. do you have comment if i combine these 2 into 1 callback? Please see the patch series I sent today regarding rmv_event_callback() fun= ction: " [PATCH 0/6] Testpmd: fix port hotplug". Yes, I think you should use rmv_event_callback() by your function (after th= e port id retrieving) to do code reuse. Regarding synchronization, let's discuss: So, the both callbacks are running from the same thread, but by different f= d. Right? So, they will be triggered sequentially by the kernel when a device is plug= ged-out and we cannot know the order. Right? The second one may get an "invalid port" error because the first one was d= etached the port - not a major issue, but the port id can be reused between them and then the second one may deta= ch an available port. Right? So, looks like it is better to choose only one of them, If all the above conclusions are correct , I suggest to disable the ethdev = mechanism when the EAL hotplug is enabled: @@ -2152,9 +2152,10 @@ struct pmd_test_command { =20 switch (type) { case RTE_ETH_EVENT_INTR_RMV: - if (rte_eal_alarm_set(100000, - rmv_event_callback, (void *)(intptr_t)port= _id)) - fprintf(stderr, "Could not set up deferred device = removal\n"); + if (!hot_plug) + if (rte_eal_alarm_set(100000, rmv_event_callback, + (void *)(intptr_t)port_id)) + fprintf(stderr, "Could not set up deferred= device removal\n"); break; default: break; What do you think? Matan. > >> /* This function is used by the interrupt thread */ static int > >> eth_event_callback(portid_t port_id, enum rte_eth_event_type type, > >> void *param, @@ -2130,9 +2153,7 @@ eth_dev_event_callback(char > >> *device_name, enum rte_dev_event_type type, > >> case RTE_DEV_EVENT_REMOVE: > >> RTE_LOG(ERR, EAL, "The device: %s has been removed!\n", > >> device_name); > >> - /* TODO: After finish failure handle, begin to stop > >> - * packet forward, stop port, close port, detach port. > >> - */ > >> + rmv_dev_event_callback(device_name); > >> break; > >> case RTE_DEV_EVENT_ADD: > >> RTE_LOG(ERR, EAL, "The device: %s has been added!\n", > @@ -2640,7 > >> +2661,7 @@ main(int argc, char** argv) > >> return -1; > >> } > >> eth_dev_event_callback_register(); > >> - > >> + rte_dev_handle_hot_unplug(); > >> } > >> > >> if (start_port(RTE_PORT_ALL) !=3D 0) > >> -- > >> 2.7.4