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 6E60D2BB9 for ; Thu, 8 Jun 2017 17:27:56 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2017 08:27:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,315,1493708400"; d="scan'208";a="1179966703" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga002.fm.intel.com with ESMTP; 08 Jun 2017 08:27:34 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.133]) by IRSMSX153.ger.corp.intel.com ([169.254.9.74]) with mapi id 14.03.0319.002; Thu, 8 Jun 2017 16:27:33 +0100 From: "Dumitrescu, Cristian" To: Thomas Monjalon CC: "Singh, Jasvinder" , "dev@dpdk.org" , "Yigit, Ferruh" , "hemant.agrawal@nxp.com" , "Jerin.JacobKollanukkaran@cavium.com" , "Lu, Wenzhuo" Thread-Topic: [dpdk-dev] [PATCH 0/2] net/softnic: sw fall-back for traffic management Thread-Index: AQHS1kofzek5gL8jNEei9E7E7OP6yqIZeFGAgAGII1CAAAEygIAAJaIA Date: Thu, 8 Jun 2017 15:27:33 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BA66B0B@IRSMSX108.ger.corp.intel.com> References: <20170526181149.44085-1-jasvinder.singh@intel.com> <3485754.OcGeoT3SaN@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA669D7@IRSMSX108.ger.corp.intel.com> <1864257.RH1pdGjOGJ@xps> In-Reply-To: <1864257.RH1pdGjOGJ@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNWY2MDdhY2QtMTZlZC00NzYzLTkxNTYtMjZhZDE4NDhmNzFmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjNtQm52WnJFdkoyQXVXTDh0dmpMT0VUNDg4Yng3eVZ3MWRuaDFzejJpR1k9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 0/2] net/softnic: sw fall-back for traffic management 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, 08 Jun 2017 15:27:57 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Thursday, June 8, 2017 3:00 PM > To: Dumitrescu, Cristian > Cc: Singh, Jasvinder ; dev@dpdk.org; Yigit, > Ferruh ; hemant.agrawal@nxp.com; > Jerin.JacobKollanukkaran@cavium.com; Lu, Wenzhuo > > Subject: Re: [dpdk-dev] [PATCH 0/2] net/softnic: sw fall-back for traffic > management >=20 > 08/06/2017 15:27, Dumitrescu, Cristian: > > Hi Thomas, > > > > Thanks for reviewing this patch set! > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > > Hi Jasvinder, > > > > > > 26/05/2017 20:11, Jasvinder Singh: > > > > The SoftNIC PMD provides SW fall-back option for the NICs not > supporting > > > > the Traffic Management (TM) features. > > > > > > Do you mean that you want to stack PMDs in order to offer some > fallbacks? > > > It means the user needs to instantiate this PMD for each HW which doe= s > > > not support traffic management, instead of normal hardware probing? > > > > > > > No, the normal HW probing still takes place for the HW device. Then if = QoS > "probing" fails, the user can decide to create a new virtual device on to= p of > the HW device. >=20 > What do you mean by "QoS probing"? Check if the hierarchy specified by the user can be met by the HW device. >=20 > > > > SoftNIC PMD overview: > > > > - The SW fall-back is based on the existing librte_sched DPDK libra= ry. > > > > - The TM-agnostic port (the underlay device) is wrapped into a TM- > aware > > > > softnic port (the overlay device). > > > > - Once the overlay device (virtual device) is created, the configur= ation > of > > > > the underlay device is taking place through the overlay device. > > > > - The SoftNIC PMD is generic, i.e. it works for any underlay device= PMD > that > > > > implements the ethdev API. > > > > > > Why not calling librte_sched directly in ethdev for PMDs which do not > > > implement hardware offload? > > > Am I missing something obvious? > > > > Yes, we are calling the librte_sched in ethdev, but how else can we do = it? >=20 > If you call librte_sched from ethdev, that's fine. > We don't need more, do we? >=20 We also need to make sure the other non-patched functionality is working as= provided by the underlying HW device. E.g. we patch TX to enable TM, but w= e don't patch RX and RX should still be working. > > - We cannot change the ethdev ops of the HW device PMD because > same might be used by other HW devices in the system where TM feature is > not required. > > - We cannot change the ethdev ops of the current HW device, as on- > the-fly changes of the ops structure are not allowed, right? >=20 > Right >=20 > > - We can create a new virtual device on top of existing HW device to > inherit most of the ethdev ops of the HW device and patch some specific > ethdev ops with librte_sched. > > > > IMHO there aren't two different ways to do this. >=20 > When initializing a HW device, it can (should) reports its TM capabilitie= s. > Then ethdev can decide to use a SW fallback if a capability is missing. Unfortunately, having the ethdev taking this decision is not possible with = the current librte_ether, as this means the changing the ethdev ops on the = fly, which you also agreed is currently not allowed. This is why we have to leave this decision to the application, which create= s the virtual device on top of the existing HW when it wants the SW fall-ba= ck to be enabled.