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

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:	Tue, 29 Nov 2011 15:57:47 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Dave Taht <dave.taht@...il.com>
Cc:	John Fastabend <john.r.fastabend@...el.com>,
	Tom Herbert <therbert@...gle.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v4 0/10] bql: Byte Queue Limits

Le mardi 29 novembre 2011 à 09:51 +0100, Dave Taht a écrit :

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

TSO makes packets larger, to lower cpu use in different layers (netfilter, qdisc, ...).

Imagine you could have MSS=65000 on your ethernet wire.

If you need to send a high prio packet while a prior big one is
in-flight on a dumb device (a single TX FIFO), there is nothing you
can do but wait last bit of big packet hit the wire.

Even with one flow you lose. Hundred flows dont matter
(as long as you have proper classification in Qdisc layer, of course)

Most setups dont care.

The ones caring dedicate a link for exclusive use, making sure it wont
cross loaded trunks. (Heartbeats in clusters)

Even disabling TSO wont be enough for them, if a single tcp flow can compete with them.

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