08/06/2017 17:27, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > 08/06/2017 15:27, Dumitrescu, Cristian:
> > > Hi Thomas,
> > >
> > > Thanks for reviewing this patch set!
> > >
> > > From: Thomas Monjalon [mailto:tho...@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.
