netdev - Re: [PATCH net v3 1/2] net: sched: tbf: fix calculation of max

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]

Date:	Sun, 24 Nov 2013 10:40:52 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Yang Yingliang <zjutyyl@...il.com>
Cc:	Yang Yingliang <yangyingliang@...wei.com>, davem@...emloft.net,
	netdev@...r.kernel.org, brouer@...hat.com, jpirko@...hat.com,
	jbrouer@...hat.com
Subject: Re: [PATCH net v3 1/2] net: sched: tbf: fix calculation of max_size

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.

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

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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html