On 7/9/20 10:04 PM, Cong Wang wrote:
> On Wed, Jul 8, 2020 at 2:07 PM YU, Xiangning
> <xiangning...@alibaba-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...@alibaba-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.
>
