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. Thanks.
