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: <20101015081826.GA7205@ff.dom.local>
Date:	Fri, 15 Oct 2010 08:18:26 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Bill Fink <billfink@...dspring.com>
Cc:	Rick Jones <rick.jones2@...com>,
	Steven Brudenell <steven.brudenell@...il.com>,
	netdev@...r.kernel.org
Subject: Re: tbf/htb qdisc limitations

On Fri, Oct 15, 2010 at 02:37:49AM -0400, Bill Fink wrote:
> On Thu, 14 Oct 2010, Jarek Poplawski wrote:
> 
> > On Thu, Oct 14, 2010 at 08:09:39AM +0000, Jarek Poplawski wrote:
> > > On Thu, Oct 14, 2010 at 03:13:54AM -0400, Bill Fink wrote:
> > > > TSO/GSO was disabled and was using 9000-byte jumbo frames
> > > > (and specified mtu 9000 to tc command).
> > > > 
> > > > Here was one attempt I made using tbf:
> > > > 
> > > > tc qdisc add dev eth2 root handle 1: prio
> > > > tc qdisc add dev eth2 parent 1:1 handle 10: tbf rate 8900mbit buffer 1112500 limit 10000 mtu 9000
> > > > tc filter add dev eth2 protocol ip parent 1: prio 1 u32 match ip dst 192.168.1.23 flowid 10:1
> > > > 
> > > > I tried many variations of the above, all without success.
> > > 
> > > The main problem are smaller packets. If you had (almost) only 9000b
> > > frames this probably could work. [...]
> > 
> > On the other hand, e.g. the limit above seems too low wrt mtu & rate.
> 
> Actually, I discovered my commands above work just fine on
> a 2.6.35 box:
> 
> i7test7% nuttcp -T10 -i1 192.168.1.17
>  1045.3125 MB /   1.00 sec = 8768.3573 Mbps     0 retrans
>  1045.6875 MB /   1.00 sec = 8772.0292 Mbps     0 retrans
>  1049.5625 MB /   1.00 sec = 8804.2627 Mbps     0 retrans
>  1043.1875 MB /   1.00 sec = 8750.9960 Mbps     0 retrans
>  1048.6875 MB /   1.00 sec = 8796.3246 Mbps     0 retrans
>  1033.4375 MB /   1.00 sec = 8669.3188 Mbps     0 retrans
>  1040.7500 MB /   1.00 sec = 8730.7057 Mbps     0 retrans
>  1047.0000 MB /   1.00 sec = 8783.2063 Mbps     0 retrans
>  1040.0000 MB /   1.00 sec = 8724.0564 Mbps     0 retrans
>  1037.4375 MB /   1.00 sec = 8702.5434 Mbps     0 retrans
> 
> 10431.5608 MB /  10.00 sec = 8749.7542 Mbps 25 %TX 35 %RX 0 retrans 0.11 msRTT
> 
> The problems I encountered were on a field system running
> 2.6.30.10.  I will investigate upgrading the field system
> to 2.6.35.

This change from 2.6.31 should matter here:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commit;h=a4a710c4a7490587406462bf1d54504b7783d7d7

Jarek P.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ