netdev - Re: [PATCH net-next 2/2] net: sched: Lockless Token Bucket (LTB) Qdisc

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: <a33f9de6-b066-6014-8be2-585203a97d89@alibaba-inc.com>
Date:   Fri, 10 Jul 2020 13:48:58 +0800
From:   "YU, Xiangning" <xiangning.yu@...baba-inc.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 2/2] net: sched: Lockless Token Bucket (LTB)
 Qdisc



On 7/9/20 10:04 PM, Cong Wang wrote:
> On Wed, Jul 8, 2020 at 2:07 PM YU, Xiangning
> <xiangning.yu@...baba-inc.com> wrote:
>>
>>
>>
>> On 7/8/20 1:24 PM, Cong Wang wrote:
>>> On Tue, Jul 7, 2020 at 2:24 PM YU, Xiangning
>>> <xiangning.yu@...baba-inc.com> wrote:
>>>>
>>>> The key is to avoid classifying packets from a same flow into different classes. So we use socket priority to classify packets. It's always going to be correctly classified.
>>>>
>>>> Not sure what do you mean by default configuration. But we create a shadow class when the qdisc is created. Before any other classes are created, all packets from any flow will be classified to this same shadow class, there won't be any incorrect classified packets either.
>>>
>>> By "default configuration" I mean no additional configuration on top
>>> of qdisc creation. If you have to rely on additional TC filters to
>>> do the classification, it could be problematic. Same for setting
>>> skb priority, right?
>>>
>>
>> In this patch we don't rely on other TC filters. In our use case, socket priority is set on a per-flow basis, not per-skb basis.
> 
> Your use case is not the default configuration I mentioned.
> 
>>
>>> Also, you use a default class, this means all unclassified packets
>>> share the same class, and a flow falls into this class could be still
>>> out-of-order, right?
>>>
>>
>> A flow will fall and only fall to this class. If we can keep the order within a flow, I'm not sure why we still have this issue?
> 
> The issue here is obvious: you have to rely on either TC filters or
> whatever sets skb priority to make packets in a flow in-order.
>> IOW, without these *additional* efforts, it is broken in terms of
> out-of-order.
> 

Well, we do ask packets from a flow to be classified to a single class, not multiple ones. It doesn't have to be socket priority, it could be five tuple hash, or even container classid.

I think it's ok to have this requirement, even if we use htb, I would suggest the same. Why do you think this is a problem?

Thanks,
- Xiangning

> Thanks.
>