Re: [dpdk-dev] [PATCH 0/2] net/softnic: sw fall-back for traffic management

[Thomas Monjalon <thomas@monjalon.net>]

08/06/2017 17:27, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 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"?
> 
> Check if the hierarchy specified by the user can be met by the HW device.
> 
> > 
> > > > > 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 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 we 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?
> > 
> > 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.
> 
> 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.

I'm sure I'm missing something.
In my understanding, we do not need to change the ops:
	- if the device offers the capability, let's call the ops
	- else call the software fallback function

> This is why we have to leave this decision to the application, which creates the virtual device on top of the existing HW when it wants the SW fall-back to be enabled.