From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 1371B2C31 for ; Sun, 12 Jun 2016 07:25:45 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 11 Jun 2016 22:25:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,460,1459839600"; d="scan'208";a="1000192597" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga002.fm.intel.com with ESMTP; 11 Jun 2016 22:25:45 -0700 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sat, 11 Jun 2016 22:25:43 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sat, 11 Jun 2016 22:25:43 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.147]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.24]) with mapi id 14.03.0248.002; Sun, 12 Jun 2016 13:25:41 +0800 From: "Lu, Wenzhuo" To: Olivier Matz , Stephen Hemminger CC: "dev@dpdk.org" , "Tao, Zhe" Thread-Topic: [dpdk-dev] [PATCH 2/8] lib/librte_ether: defind RX/TX lock mode Thread-Index: AQHRv7YPz+AiAd9UVkaKCUmVRYxRo5/eUdWAgADcisCAARNogIAFD3Gw Date: Sun, 12 Jun 2016 05:25:41 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC090903484BFF@shsmsx102.ccr.corp.intel.com> References: <1465191653-28408-1-git-send-email-wenzhuo.lu@intel.com> <1465191653-28408-3-git-send-email-wenzhuo.lu@intel.com> <20160607191553.10993efe@xeon-e3> <6A0DE07E22DDAD4C9103DF62FEBC090903483A7F@shsmsx102.ccr.corp.intel.com> <57591FE1.9070908@6wind.com> In-Reply-To: <57591FE1.9070908@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 2/8] lib/librte_ether: defind RX/TX lock mode X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 05:25:46 -0000 Hi Olivier, > -----Original Message----- > From: Olivier Matz [mailto:olivier.matz@6wind.com] > Sent: Thursday, June 9, 2016 3:51 PM > To: Lu, Wenzhuo; Stephen Hemminger > Cc: dev@dpdk.org; Tao, Zhe > Subject: Re: [dpdk-dev] [PATCH 2/8] lib/librte_ether: defind RX/TX lock m= ode >=20 > Hi, >=20 > On 06/08/2016 09:34 AM, Lu, Wenzhuo wrote: > > Hi Stephen, > > > > > >> -----Original Message----- > >> From: Stephen Hemminger [mailto:stephen@networkplumber.org] > >> Sent: Wednesday, June 8, 2016 10:16 AM > >> To: Lu, Wenzhuo > >> Cc: dev@dpdk.org; Tao, Zhe > >> Subject: Re: [dpdk-dev] [PATCH 2/8] lib/librte_ether: defind RX/TX > >> lock mode > >> > >> On Mon, 6 Jun 2016 13:40:47 +0800 > >> Wenzhuo Lu wrote: > >> > >>> Define lock mode for RX/TX queue. Because when resetting the device > >>> we want the resetting thread to get the lock of the RX/TX queue to > >>> make sure the RX/TX is stopped. > >>> > >>> Using next ABI macro for this ABI change as it has too much impact. > >>> 7 APIs and 1 global variable are impacted. > >>> > >>> Signed-off-by: Wenzhuo Lu > >>> Signed-off-by: Zhe Tao > >> > >> Why does this patch set make a different assumption the rest of the DP= DK? > >> > >> The rest of the DPDK operates on the principle that the application > >> is smart enough to stop the device before making changes. There is no > >> equivalent to the Linux kernel RTNL mutex. The API assumes > >> application threads are well behaved and will not try and sabotage eac= h > other. > >> > >> If you restrict the reset operation to only being available when > >> RX/TX is stopped, then no lock is needed. > >> > >> The fact that it requires lots more locking inside each device driver > >> implies to me this is not correct way to architect this. >=20 > +1 >=20 > I'm not sure adding locks is the proper way to do. > This is the application responsibility to ensure that: > - control functions are not called concurrently on the same port > - rx/tx functions are not called when the device is stopped/reset/... >=20 > However, I do think the usage paradigms of the ethdev api should be bette= r > documented in rte_ethdev.h (ex: which functions can be called concurrentl= y). > This would be a first step. >=20 > If we really want a helper API to do that in DPDK, the _next_ step could = be to > add them in the ethdev api to achieve this. Maybe something like (the fun= ction > names could be better): >=20 > - to be called on one control thread: >=20 > rte_eth_stop_rxtx(port) > rte_eth_start_rxtx(port) >=20 > rte_eth_get_rxtx_state(port) > -> return "running" if at least one core is inside the rx/tx code > -> return "stopped" if all cores are outside the rx/tx code >=20 > - to be called on dataplane cores: >=20 > /* same than rte_eth_rx_burst(), but checks if rx/tx is allowed > * first, else do nothing */ > rte_eth_rx_burst_interruptible() > rte_eth_tx_burst_interruptible() >=20 >=20 > The code of control thread could be: >=20 > rte_eth_stop_rxtx(port); > /* wait that all dataplane cores finished their processing */ > while (rte_eth_get_rxtx_state(port) !=3D stopped) > ; > rte_eth_some_control_operation(port); > rte_eth_start_rxtx(port); >=20 >=20 > I think this could be done without any lock, just with the proper memory = barriers > and a per-core status. >=20 > But this API may impose a paradigm to the application, and I'm not sure t= he > DPDK should do that. I don't quite catch your point. Seems your solution still need the APP to c= hange the code. I think it's more complex than just letting the APP to stop= the rx/tx and reset the port. Our purpose of this patch set is to let APP = do less as possible. It's not a good choice if we make it more complex. And seems it's hard to stop and start rx/tx in rte layer. Normally APP shou= ld do that. To my opinion, we have to introduce lock in rte to achieve that= . >=20 > Regards, > Olivier