lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ