[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a7038ca-2f6f-30f6-e168-6a3510db0db7@gmail.com>
Date: Wed, 11 Mar 2020 18:01:38 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Petr Machata <petrm@...lanox.com>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.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
On 3/11/20 5:42 PM, Petr Machata wrote:
>
> Eric Dumazet <eric.dumazet@...il.com> writes:
>
>> On 3/11/20 10:33 AM, Petr Machata wrote:
>>> 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.
>>>
>>> To that end, add 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.
>>>
>>
>> I find the naming of the feature very confusing.
>>
>> When enabling this new feature, we no longer drop packets
>> that could not be CE marked.
>> Tail drop is already in the packet scheduler, you want to disable it.
>>
>>
>> How this feature has been named elsewhere ???
>> (you mentioned in your cover letter :
>> "Some switches support this mode, and some installations make use of it.")
>
> The two interfaces that I know about are Juniper and Cumulus. I don't
> know either from direct experience, but from the manual, Cumulus seems
> to allow enablement of either ECN on its own[0], or ECN with RED[1]. (Or
> RED on its own I presume, but I couldn't actually find that.)
>
> In Juniper likewise, "on ECN-enabled queues, the switch [...] uses the
> tail-drop algorithm to drop non-ECN-capable packets during periods of
> congestion"[2]. You need to direct non-ECT traffic to a different queue
> and configure RED on that to get the RED+ECN behavior ala Linux.
>
> So this is unlike the RED qdisc, where RED is implied, and needs to be
> turned off again by an anti-RED flag. The logic behind the chosen flag
> name is that the opposite of early dropping is tail dropping. Note that
> Juniper actually calls it that as well.
>
> 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 :)
>
> [0] https://docs.cumulusnetworks.com/cumulus-linux-40/Layer-1-and-Switch-Ports/Buffer-and-Queue-Management/
> [1] https://docs.cumulusnetworks.com/version/cumulus-linux-37/Network-Solutions/RDMA-over-Converged-Ethernet-RoCE/
> [2] https://www.juniper.net/documentation/en_US/junos/topics/concept/cos-qfx-series-tail-drop-understanding.html
>
Powered by blists - more mailing lists