Hi Thomas, Thanks for reviewing this patch set!
> -----Original Message----- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Wednesday, June 7, 2017 3:32 PM > To: Singh, Jasvinder <jasvinder.si...@intel.com> > Cc: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitre...@intel.com>; > Yigit, Ferruh <ferruh.yi...@intel.com>; hemant.agra...@nxp.com; > jerin.jacobkollanukka...@cavium.com; Lu, Wenzhuo > <wenzhuo...@intel.com> > Subject: Re: [dpdk-dev] [PATCH 0/2] net/softnic: sw fall-back for traffic > management > > 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. > > 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? - 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? - 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. Regards, Cristian
