[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h7ytyj32.fsf@mellanox.com>
Date: Thu, 12 Mar 2020 11:16:01 +0100
From: Petr Machata <petrm@...lanox.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
Roman Mashak <mrv@...atatu.com>, jhs@...atatu.com,
xiyou.wangcong@...il.com, davem@...emloft.net, jiri@...lanox.com,
mlxsw@...lanox.com
Subject: Re: [PATCH net-next v2 3/6] net: sched: RED: Introduce an ECN tail-dropping mode
Jakub Kicinski <kuba@...nel.org> writes:
> On Wed, 11 Mar 2020 18:01:38 -0700 Eric Dumazet wrote:
>> > That said, I agree that from the perspective of the qdisc itself the
>> > name does not make sense. We can make it "nodrop", or "nored", or maybe
>> > "keep_non_ect"... I guess "nored" is closest to the desired effect.
>>
>> Well, red algo is still used to decide if we attempt ECN marking, so "nodrop"
>> seems better to me :)
I know that the D in RED could stand for "detection", but the one in RED
as a qdisc kind certainly stands for "drop" :)
> nodrop + harddrop is a valid combination and that'd look a little
> strange. Maybe something like ect-only?
But then "ecn ect_only" would look equally strange. Like, of course ECN
is ECT only...
I don't actually mind "nodrop harddrop". You can't guess what these
flags do from just their names anyway, so the fact they don't seem to
make sense next to each other is not an issue. And "nodrop" does
describe what the immediate behavior in context of the RED qdisc is.
Powered by blists - more mailing lists