Re: [PATCH net v3 1/2] net: sched: tbf: fix calculation of max_size

[Yang Yingliang <yangyingliang@huawei.com>]

On 2013/11/25 2:40, Eric Dumazet wrote:
> On Sun, 2013-11-24 at 15:28 +0800, Yang Yingliang wrote:
>> O>
>>>> With the follow command:
>>>> tc qdisc add dev eth1 root handle 1: tbf latency 50ms burst 10KB rate 30gbit mtu 64k
>>>>
>>>
>> Ideally burst should be 10KB in kernel space.
>> But at hight rates, when burst is converted to
>> time in tick in userland, it gets much more loss
>> than low rates. So the burst can't actually
>> reach 10KB in kernel.
> 
> If you think tc can help to fix user choices, please provide an
> iproute2 patch.

Unfortunately, it can't. It always has some loss when burst in bytes
is converted to buffer in ticks, we cannot avoid it, except we send burst
to kernel directly, this need to modify the code both in iproute2 and kernel.

> 
> Quite frankly, using a burst of 10KB and a rate of 30gbit is simply a
> user error. It cannot possibly work. At all.

Yep, I agree it's a user error. But the error may cause network down, and
we have a way to avoid it, I think we should fix it. :)

> 
> As stated in many tbf docs, burst must be larger than device mtu (1514)
> 
> By extension, with GRO/GSO, burst should be larger than 68130, otherwise
> we need to segment the packets, and this is horribly expensive for high
> rates.
> 
> I personally tc/tbf needs some changes, because the logical way would be
> to use the 1514 value for low rates, but if we use this value, the
> kernel gets a value of 1511, which doesn't work.

Yep, I agree with your logical way. But I think current logic in kernel
cannot support to only do some changes in tc/tbf. We need changes both
in tc and kernel. I'll post a patch which uses TCA_TBF_BURST to get burst
from tc directly and this patch also need to keep backward compatible with
old tc.

Regards,
Yang