netdev - RE: [PATCH 7/7 net-next] tg3: Change default number of tx rings to 1.

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] [day] [month] [year] [list]

Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B700E@saturn3.aculab.com>
Date:	Fri, 28 Sep 2012 10:07:19 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"David Miller" <davem@...emloft.net>, <mchan@...adcom.com>
Cc:	<netdev@...r.kernel.org>
Subject: RE: [PATCH 7/7 net-next] tg3: Change default number of tx rings to 1.

> > In the simplest case, assume you have 2 TCP streams running in opposite
> > directions.  The TX traffic (mostly TSO) will hash to one tx ring.  The
> > ACKs for the incoming data on a different TCP connection will hash to
> > another TX ring.  The hardware fetches one complete TSO packet from the
> > first ring (up to 64K data) before servicing the other TX ring.  And
> > when it gets to the other TX ring, it will fetch only one packet (one
> > 64-byte ACK packet in this case) and then immediately switches back to
> > the 1st ring (filled with more TSO packets).  In reality, there may be
> > over 10 ACK packets waiting in the 2nd ring because a lot of incoming
> > data has been received and ACKed during this time.  Because the ACKs are
> > going out so slowly, the incoming throughput slows to a trickle.
> 
> Thanks for the explanation, this is the kind of text that belongs in
> the commit message.  Otherwise the next person who reads the patch,
> like me, will ask why this is being done.

And also in the code somewhere.

	David



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