From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id DC8F19603 for ; Wed, 8 Jun 2016 09:35:10 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 08 Jun 2016 00:34:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,438,1459839600"; d="scan'208";a="997593450" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga002.fm.intel.com with ESMTP; 08 Jun 2016 00:34:49 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 8 Jun 2016 00:34:46 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 8 Jun 2016 00:34:45 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.147]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.181]) with mapi id 14.03.0248.002; Wed, 8 Jun 2016 15:34:44 +0800 From: "Lu, Wenzhuo" To: 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/eUdWAgADcisA= Date: Wed, 8 Jun 2016 07:34:43 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC090903483A7F@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> In-Reply-To: <20160607191553.10993efe@xeon-e3> 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: Wed, 08 Jun 2016 07:35:11 -0000 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 m= ode >=20 > On Mon, 6 Jun 2016 13:40:47 +0800 > Wenzhuo Lu wrote: >=20 > > 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 >=20 > Why does this patch set make a different assumption the rest of the DPDK? >=20 > The rest of the DPDK operates on the principle that the application is sm= art > enough to stop the device before making changes. There is no equivalent t= o the > Linux kernel RTNL mutex. The API assumes application threads are well beh= aved > and will not try and sabotage each other. >=20 > If you restrict the reset operation to only being available when RX/TX is= stopped, > then no lock is needed. >=20 > The fact that it requires lots more locking inside each device driver imp= lies to me > this is not correct way to architect this. It's a good question. This patch set doesn't follow the regular assumption = of DPDK. But it's a requirement we've got from some customers. The users want the dr= iver does as much as it can. The best is the link state change is transpare= nt to the users. The patch set tries to provide another choice if the users don't want to st= op their rx/tx to handle the reset event. And as discussed in the other thread, most probably we will move the lock f= rom the PMD layer to rte lay. It'll avoid the change in every device.