Thread (26 messages) 26 messages, 9 authors, 2011-12-02

Re: [PATCH v4 0/10] bql: Byte Queue Limits

From: Dave Taht <hidden>
Date: 2011-11-29 08:51:44

On Tue, Nov 29, 2011 at 9:43 AM, Eric Dumazet [off-list ref] wrote:
Le mardi 29 novembre 2011 à 09:37 +0100, Dave Taht a écrit :
quoted
On Tue, Nov 29, 2011 at 8:23 AM, John Fastabend
[off-list ref] wrote:
quoted
I wonder if we should consider enabling TSO/GSO per queue or per traffic
class on devices that support this. At least in devices that support
multiple traffic classes it seems to be a common usage case to put bulk
storage traffic (iSCSI) on a traffic class and low latency traffic on a
separate traffic class, VoIP for example.

VOIP is a drop in the bucket.

Turning TSO off on TCP exiting the datacenter (or more specifically),
destined anywhere there is potential tx/rx bandwidth disparity
would be goooooood.
If your cpu is fast enough (and they are most of the time), this makes
no difference at all.

Instead of consuming 3% of cpu with TSO, you'll consume 10% or 15% and
no difference seen on the wire.
Perhaps I don't understand the gross effects of TSO very well, but if you have
100 streams coming from a server, destined to X different destinations,
and you FQ to each on a per packet basis, you end up impacting the downstream
receive buffers throughout much less than if you send each stream as a burst.
Really, if you want to avoid bursts, TSO has litle to do with them.
If I'm misunderstanding the downstream effects of TSO, I stand corrected.



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help