From: Dave Taht <dave.taht@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Gautam Ramakrishnan <gautamramk@gmail.com>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
Jamal Hadi Salim <jhs@mojatatu.com>,
"David S. Miller" <davem@davemloft.net>,
Cong Wang <xiyou.wangcong@gmail.com>,
Leslie Monis <lesliemonis@gmail.com>,
"Mohit P . Tahiliani" <tahiliani@nitk.edu.in>
Subject: Re: [net-next] net: sched: pie: enable timestamp based delay calculation
Date: Tue, 27 Aug 2019 09:58:50 -0700 [thread overview]
Message-ID: <CAA93jw6PJXsG++0c+mE8REUb0cD4PU2Xck-J9fD1miuKfxS6BQ@mail.gmail.com> (raw)
In-Reply-To: <316fdac3-5fa9-35d5-ad74-94072f19c5fc@gmail.com>
On Tue, Aug 27, 2019 at 8:34 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 8/27/19 4:19 PM, Gautam Ramakrishnan wrote:
> > RFC 8033 suggests an alternative approach to calculate the queue
> > delay in PIE by using per packet timestamps. This patch enables the
> > PIE implementation to do this.
> >
> > The calculation of queue delay is as follows:
> > qdelay = now - packet_enqueue_time
> >
> > To enable the use of timestamps:
> > modprobe sch_pie use_timestamps=1
>
>
> No module parameter is accepted these days.
>
> Please add a new attribute instead,
> so that pie can be used in both mode on the same host.
I note that I think (but lack independent data) this improvement to
the rate estimator in pie should improve its usability and accuracy
in low rate or hw mq situations, and with some benchmarking to
show the cpu impact (at high and low rates) of this improvement as
well as the network
impact, the old way should probably be dropped and new way adopted without
needing a new variable to control it.
A commit showing the before/after cpu and network impact with a whole
bunch of flent benchmarks would be great.
(I'd also love to know if pie can be run with a lower target - like 5ms -
with this mod in place)
>
> For a typical example of attribute addition, please take
> a look at commit 48872c11b77271ef9b070bdc50afe6655c4eb9aa
> ("net_sched: sch_fq: add dctcp-like marking")
utilizing ce_threshold in this way is actually independent of whether or
not you are using dctcp-style or rfc3168 style ecn marking.
It's "I'm self congesting... Dooo something! Anything, to reduce the load!"
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
next prev parent reply other threads:[~2019-08-27 16:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 14:19 [net-next] net: sched: pie: enable timestamp based delay calculation Gautam Ramakrishnan
2019-08-27 15:34 ` Eric Dumazet
2019-08-27 16:58 ` Dave Taht [this message]
2019-08-29 7:21 ` Gautam Ramakrishnan
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=CAA93jw6PJXsG++0c+mE8REUb0cD4PU2Xck-J9fD1miuKfxS6BQ@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=gautamramk@gmail.com \
--cc=jhs@mojatatu.com \
--cc=lesliemonis@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=tahiliani@nitk.edu.in \
--cc=xiyou.wangcong@gmail.com \
/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).