08/06/2017 17:27, Dumitrescu, Cristian:

From: Thomas Monjalon [mailto:thomas@monjalon.net]

quoted

08/06/2017 15:27, Dumitrescu, Cristian:

quoted

Hi Thomas,

Thanks for reviewing this patch set!

From: Thomas Monjalon [mailto:thomas@monjalon.net]

quoted

Hi Jasvinder,

26/05/2017 20:11, Jasvinder Singh:

quoted

The SoftNIC PMD provides SW fall-back option for the NICs not

supporting

quoted

quoted

quoted

the Traffic Management (TM) features.

Do you mean that you want to stack PMDs in order to offer some

fallbacks?

quoted

quoted

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.

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

  softnic port (the overlay device).
- Once the overlay device (virtual device) is created, the configuration

of

quoted

quoted

quoted

  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

quoted

quoted

quoted

  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.

quoted

quoted

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

quoted

	- 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

quoted

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

quoted

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.