[dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierarchical scheduler

[Dumitrescu, Cristian]

Hi Steve,

Thanks for your comments!


> This seems to be more of an abstraction of existing QoS.

Really? Why exactly do you say this, any particular examples?

I think the current proposal provides an abstraction for far more features than librte_sched provides. The goal for this API is to be able to describe virtually any hierarchy that could be implemented in HW and/or SW, not just what is currently provided by librte_sched.

If your statement is true, then I failed in my mission, and hopefully I didn't :)


> Why not something like Linux Qdisc or FreeBSD DummyNet/PF/ALTQ where the Qos components are stackable objects? 

After designing Packet Framework, I don't think anybody could suspect me of not being a fan of stackable objects ;). Not sure why you say this either, as basically current proposal builds the hierarchy out of inter-connected nodes sitting on top of shapers and WRED contexts. To me, this is a decent stack?

I don't think this proposal is that far away from Linux qdisc: qdisc classes are nodes, shapers are present, WRED contexts as well. Any particular qdisc feature you see missing?

Of course, Linux qdisc also includes classification, policing, marking, etc which are outside of the hierarchical scheduling that is targeted by this proposal. But this is an interesting thought: designing a qdisc-like layer within DPDK that binds together classification, policing, filters, scheduling.


> And why not make it the same as existing OS abstractions?

Do you mean using the Linux qdisc API and implementation as is? Of course, this is GPL licensed code and we cannot do this in DPDK.

Do you mean having a Linux qdisc-like API? I largely agree with this, and I think the current proposal is very much inline with this; if you think otherwise, again, specific examples of what's missing would help a lot. I can also take a look at DummyNet to make sure there is nothing left behind.


> Rather than reinventing wheel which seems to be DPDK Standard Procedure, could an existing abstraction be used?

I thought we are just trying to create a car instead of a faster horse :)


Regards,
Cristian