From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH 0/2] net/softnic: sw fall-back for traffic
	management
Date: Thu, 08 Jun 2017 15:59:51 +0200
Message-ID: <1864257.RH1pdGjOGJ@xps>
References: <20170526181149.44085-1-jasvinder.singh@intel.com>
 <3485754.OcGeoT3SaN@xps>
 <3EB4FA525960D640B5BDFFD6A3D891267BA669D7@IRSMSX108.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: "Singh, Jasvinder" <jasvinder.singh@intel.com>, dev@dpdk.org, "Yigit,
 Ferruh" <ferruh.yigit@intel.com>,
 "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
 "Jerin.JacobKollanukkaran@cavium.com" <Jerin.JacobKollanukkaran@cavium.com>,
 "Lu, Wenzhuo" <wenzhuo.lu@intel.com>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id D86AA2BB9
 for <dev@dpdk.org>; Thu,  8 Jun 2017 15:59:52 +0200 (CEST)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BA669D7@IRSMSX108.ger.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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 does
> > 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 top of the HW device.

What do you mean by "QoS probing"?

> > > SoftNIC PMD overview:
> > > - The SW fall-back is based on the existing librte_sched DPDK library.
> > > - 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 configuration 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?

If you call librte_sched from ethdev, that's fine.
We don't need more, do we?

> 	- 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?

Right

> 	- 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.

When initializing a HW device, it can (should) reports its TM capabilities.
Then ethdev can decide to use a SW fallback if a capability is missing.