Re: [PATCH net-next v5] sched: Add dualpi2 qdisc
From: Bob Briscoe
Date: Thu Aug 29 2019 - 18:19:03 EST
Dave,
On 28/08/2019 17:55, Dave Taht wrote:
On Wed, Aug 28, 2019 at 7:00 AM Bob Briscoe <research@xxxxxxxxxxxxxx> wrote:
Olivier, Dave,
On 23/08/2019 13:59, Tilmans, Olivier (Nokia - BE/Antwerp) wrote:
as best as I can
tell (but could be wrong) the NQB idea wants to put something into the
l4s fast queue? Or is NQB supposed to
be a third queue?
NQB is not supported in this release of the code. But FYI, it's not for a third queue.
At the time of my code review of dualpi I had not gone back to review
the NQB draft fully.
We can add support for NQB in the future, by expanding the
dualpi2_skb_classify() function. This is however out of scope at the
moment as NQB is not yet adopted by the TSV WG. I'd guess we may want more
than just the NQB DSCP codepoint in the L queue, which then warrant
another way to classify traffic, e.g., using tc filter hints.
Yes, you'll find find folk are fans of being able to put tc (and ebpf)
filters in front of various qdiscs for classification, logging, and/or
dropping behavior.
A fairly typical stanza is here:
https://github.com/torvalds/linux/blob/master/net/sched/sch_sfq.c#L171
to line 193.
Yes, I got a student to add hooks for the Linux classification
architecture (either adding more, or overriding the defaults) a couple
of years ago, along with creating a classful structure. But his
unfinished branch got left dangling once he graduated and is now way out
of date. it's still our intention to take that direction tho.
The IETF adopted the NQB draft at the meeting just passed in July, but the draft has not yet been updated to reflect that: https://tools.ietf.org/html/draft-white-tsvwg-nqb-02
Hmmm... no. I think oliver's statement was correct.
NQB was put into the "call for adoption into tsvwg" state (
https://mailarchive.ietf.org/arch/msg/tsvwg/fjyYQgU9xQCNalwPO7v9-al6mGk
) in the tsvwg aug 21st, which
doesn't mean "adopted by the ietf", either.
You're right.
I've been away from all this for a while. In the tsvwg meeting there
were perhaps a couple of dozen folks stating support and no-one against,
so I had (wrongly) extrapolated from that - I should have checked the
status of the ML discussion first.
In response to that call
several folk did put in (rather pithy),
comments on the current state of the NQB idea and internet draft, starting here:
https://mailarchive.ietf.org/arch/msg/tsvwg/hZGjm899t87YZl9JJUOWQq4KBsk
While using up ECT1 in the L4S code as an identifier and not as a
congestion indicator is very controversial for me (
https://lwn.net/Articles/783673/ ), AND I'd rather it not be baked
into the linux api for dualpi should this identifier not be chosen by
the wg (thus my suggestion of a mask or lookup table)...
That ship has sailed. You can consider it controversial if you want, but
the tsvwg decided to use ECT(1) as an identifier for L4S after long
discussions back in 2016. Years of a large number of people's work was
predicated on that decision. So the dualpi2 code reflects the way the
IETF is approaching this.
... I also dearly would like both sides of this code - dualpi and tcp
prague - in a simultaneously testable and high quality state. Without
that, many core ideas in dualpi cannot be tested, nor objectively
evaluated against other tcps and qdiscs using rfc3168 behavior along
the path. Multiple experimental ideas in RFC8311 (such as those in
section 4.3) have also not been re-evaluated in any context.
We're working on that - top priority now.
Is the known to work reference codebase for "tcp prague" still 3.19 based?
It is, but Olivier recently found the elusive cause of the problem that
made later versions bursty. So we're getting close.
Bob
Bob
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
--
Dave TÃht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/