From: Dumitrescu, Cristian

quoted

-----Original Message-----
From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
Sent: Monday, March 6, 2017 8:07 PM
To: Dumitrescu, Cristian <redacted>
Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com;
balasubramanian.manoharan@cavium.com; hemant.agrawal@nxp.com;
shreyansh.jain@nxp.com; Wiles, Keith [off-list ref];

Richardson,

quoted

Bruce [off-list ref]
Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API

2017-03-06 16:59, Dumitrescu, Cristian:

quoted

From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]

quoted

2017-03-04 01:10, Cristian Dumitrescu:

quoted

This patch introduces the generic ethdev API for the traffic

manager

quoted

quoted

quoted

quoted

capability, which includes: hierarchical scheduling, traffic

shaping,

quoted

quoted

quoted

quoted

congestion management, packet marking.

We already have some API for QoS. Why integrating them in ethdev?
ethdev is an interface for networking drivers.
I think the QoS has nothing to do with drivers.
If there are some operations to offload in drivers, please

identify them

quoted

quoted

quoted

and let's add the operations to ethdev.

The reason to add to ethdev is because QoS traffic

management/hierarchical scheduling is just another TX offload for

Ethernet

quoted

devices. This TX offload is present in NICs, NPUs and SoCs from

Broadcom,

quoted

Cavium, Intel, Mellanox, Netronome, NXP, others.

quoted

The API we currently have in DPDK (librte_sched) is great, but it

refers to

quoted

an implementation for a fixed set of features for a BRAS-like

hierarchy. The

quoted

current abstraction layer proposal is intended to support pretty much

any

quoted

hierarchy and traffic management features such as hierarchical

scheduling,

quoted

traffic shaping, congestion management, marking under the same API. It
targets pretty much any implementation, either HW, SW or hybrid; it

does

quoted

support the existing librte_sched library feature set, but it is not

limited to it.

quoted

OK I better understand now.
You should add this level of explanation in your patch.

However I am reluctant to add an API if there is no user.
I think we should wait to have at least one existing driver

implementing

quoted

this API before integrating it.
It was the approach of eventdev which has a dedicated next- tree.

The next-tree solution could work, but IMO is not the best for this
case, as this is purely driver development. This is just a TX offload
feature that is well understood, as opposed to a new library with a huge
design effort required like eventdev.

I think we are reasonably close to get agreement on the API from Cavium,
Intel and NXP. When this is done, how about including it in DPDK with
the experimental tag attached to it until several drivers implement it?

From Intel side, there are solid plans to implement it for ixgbe and
i40e drivers in next DPDK releases, I am CC-ing Tim to confirm this.

That's correct. We plan to add support for this in the ixgbe and i40e drivers in 17.08.

On
Cavium and NXP side, Jerin and Hemant can comment on the plans to
implement this API.