[dpdk-dev] [PATCH 0/2] net/softnic: sw fall-back for traffic management
Dumitrescu, Cristian
cristian.dumitrescu at intel.com
Thu Jun 8 15:27:15 CEST 2017
Hi Thomas,
Thanks for reviewing this patch set!
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Wednesday, June 7, 2017 3:32 PM
> To: Singh, Jasvinder <jasvinder.singh at intel.com>
> Cc: dev at dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu at intel.com>;
> Yigit, Ferruh <ferruh.yigit at intel.com>; hemant.agrawal at nxp.com;
> Jerin.JacobKollanukkaran at cavium.com; Lu, Wenzhuo
> <wenzhuo.lu at 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
More information about the dev
mailing list