From: Eric Dumazet <eric.dumazet@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: David Miller <davem@davemloft.net>, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] fq_codel: dont reinit flow state
Date: Mon, 03 Sep 2012 01:17:40 +0200 [thread overview]
Message-ID: <1346627860.2563.64.camel@edumazet-glaptop> (raw)
In-Reply-To: <CAA93jw6mdAaomNfNWt0D4MZYFqXZ3=P+HYe9AEkvwNkAH84GSQ@mail.gmail.com>
On Sat, 2012-09-01 at 11:12 -0700, Dave Taht wrote:
> partial NAK.
Kind of weird to NACK a patch you are the author.
It makes both of us plain fools on netdev, dont do that.
> There is no need to reset dropped either, and resetting quantum or not
> is an interesting question.
>
Yes but totally unrelated to this patch.
It would be good you pollute threads.
Open a new thread, using RFC attribute or something.
> (in both cases they can be initted at init time)
>
> Lastly, stats->maxpacket is presently a shared resource in fq_codel,
> and the initial setting of 256 was an artifact some test ns2 code
> (according to kathie). In the case of ack traffic owning a queue, this
> can be 64 or 66 bytes (or larger on ipv6 acks).
>
I really hope you understand how this maxpacket thing is useless ?
In the real life, we dont send only 66 bytes packets.
maxpacket purpose is to relax codel so that it doesnt drop packet if
the qdisc backlog is small (so about to be empty).
Rename this maxpacket to 'relax_codel_under_that_size' if you want to.
> It's totally unclear if this distinction is important in fq_codel at
> present. :/. Obviously in codel which is a pure FIFO, maxpacket will
> hit the max size really fast.
>
> A related problem on maxpacket is if someone turns off tso/gso/ufo, it
> remains set to the largest packet seen forever until the qdisc is
> re-initialized.
> This leads to really puzzling behavior... (I'll submit a patch for
> this shortly but not change fq_codel's
> centralized stats)
>
> I'd be happy (for now) if dropped was preserved,
> and to fiddle with the other ideas a while longer.
>
There is no dropped field, what are you talking about ?
If you are now unsure of the patch, I can repost the same patch but
as the author.
Its a real obvious one. After an idle period, CODEL needs to compute the
delay between now and previous 'drop_next'
Codel doesnt call codel_vars_init() but in the qdisc init.
fq_codel being FQ + CODEL, it is an error to call codel_vars_init()
outside of init path.
next prev parent reply other threads:[~2012-09-02 23:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-01 13:19 [PATCH] fq_codel: dont reinit flow state Eric Dumazet
2012-09-01 18:12 ` Dave Taht
2012-09-02 23:17 ` Eric Dumazet [this message]
2012-09-03 0:08 ` Dave Taht
2012-09-03 18:37 ` David Miller
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=1346627860.2563.64.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=dave.taht@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.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