From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierarchical scheduler
Date: Wed, 7 Dec 2016 19:03:34 +0000 [thread overview]
Message-ID: <3EB4FA525960D640B5BDFFD6A3D89126527112A9@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <20161206115124.67ccc0c7@xeon-e3>
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
next prev parent reply other threads:[~2016-12-07 19:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 18:16 Cristian Dumitrescu
2016-12-06 19:51 ` Stephen Hemminger
2016-12-06 22:14 ` Thomas Monjalon
2016-12-07 20:13 ` Dumitrescu, Cristian
2016-12-07 19:03 ` Dumitrescu, Cristian [this message]
[not found] ` <57688e98-15d5-1866-0c3a-9dda81621651@brocade.com>
2016-12-07 10:58 ` Alan Robertson
2016-12-07 19:52 ` Dumitrescu, Cristian
2016-12-08 15:41 ` Alan Robertson
2016-12-08 17:18 ` Dumitrescu, Cristian
2016-12-09 9:28 ` Alan Robertson
2016-12-08 10:14 ` Bruce Richardson
2017-01-11 13:56 ` Jerin Jacob
2017-01-13 10:36 ` Hemant Agrawal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EB4FA525960D640B5BDFFD6A3D89126527112A9@IRSMSX108.ger.corp.intel.com \
--to=cristian.dumitrescu@intel.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).