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