[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120928.004912.1130579693973926556.davem@davemloft.net>
Date: Fri, 28 Sep 2012 00:49:12 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: mchan@...adcom.com
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH 7/7 net-next] tg3: Change default number of tx rings to
1.
From: "Michael Chan" <mchan@...adcom.com>
Date: Thu, 27 Sep 2012 21:44:31 -0700
> 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.
> Our other devices don't do this simple Round-robin tx scheduling.
> Instead, there are independent DMA channels fetching and interleaving tx
> data from multiple rings.
Ok.
Please respin your patch set, adding the detailed explanation you gave
me here to the TX queue change, and I will apply it.
Thanks.
--
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