netdev - Re: [PATCH] Disable TSO for non standard qdiscs

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: <47A21E1A.6000006@hp.com>
Date:	Thu, 31 Jan 2008 11:14:34 -0800
From:	Rick Jones <rick.jones2@...com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH] Disable TSO for non standard qdiscs

Andi Kleen wrote:
>>So, at what timescale do people using these qdiscs expect things to 
>>appear "smooth?"  64KB of data at GbE speeds is something just north of 
>>half a millisecond unless I've botched my units somewhere.
> 
> 
> One typical use case for TBF is you talking to a DSL bridge that 
> is connected using a GBit Ethernet switch. For these DSL connections it gives
> much better behaviour to shape the traffic to slightly below
> your external link speed so that you can e.g. prioritize packets properly.

Sounds like the functionality needs to be in the DSL bridge :) (or the 
"router" in the same case) Particularly since it might be getting used 
by more than one host on the GbE switch.

> But the actual external link speed is much lower than GbE.
> A lot of GbE NICs enable TSO by default.

bluesky typing...

then the qdisc could/should place a cap on the size of a 'TSO' based on 
the bitrate (and perhaps input as to how much time any one "burst" of 
data should be allowed to consume on the network) and pass that up the 
stack?  right now you seem to be proposing what is effectively a cap of 
1 MSS.

rick jones
--
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