[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878sk0y3gk.fsf@mellanox.com>
Date: Mon, 16 Mar 2020 11:54:51 +0100
From: Petr Machata <petrm@...lanox.com>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, kuba@...nel.org, mrv@...atatu.com,
jhs@...atatu.com, xiyou.wangcong@...il.com, jiri@...lanox.com,
mlxsw@...lanox.com
Subject: Re: [PATCH net-next v2 0/6] RED: Introduce an ECN tail-dropping mode
David Miller <davem@...emloft.net> writes:
> From: Petr Machata <petrm@...lanox.com>
> Date: Wed, 11 Mar 2020 19:33:50 +0200
>
>> When the RED qdisc is currently configured to enable ECN, the RED algorithm
>> is used to decide whether a certain SKB should be marked. If that SKB is
>> not ECN-capable, it is early-dropped.
>>
>> It is also possible to keep all traffic in the queue, and just mark the
>> ECN-capable subset of it, as appropriate under the RED algorithm. Some
>> switches support this mode, and some installations make use of it.
>> There is currently no way to put the RED qdiscs to this mode.
>>
>> Therefore this patchset adds a new RED flag, TC_RED_TAILDROP. When the
>> qdisc is configured with this flag, non-ECT traffic is enqueued (and
>> tail-dropped when the queue size is exhausted) instead of being
>> early-dropped.
> ...
>
> Series applied, thank you.
Dave, there were v3 and v4 for this patchset as well. They had a
different subject, s/taildrop/nodrop/, hence the confusion I think.
Should I send a delta patch with just the changes, or do you want to
revert-and-reapply, or...?
Powered by blists - more mailing lists