[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46D312F6.9080404@hp.com>
Date: Mon, 27 Aug 2007 11:07:50 -0700
From: Rick Jones <rick.jones2@...com>
To: David Miller <davem@...emloft.net>
Cc: jheffner@....edu, billfink@...dspring.com, hadi@...erus.ca,
krkumar2@...ibm.com, gaagaan@...il.com,
general@...ts.openfabrics.org, herbert@...dor.apana.org.au,
jagana@...ibm.com, jeff@...zik.org, johnpol@....mipt.ru,
kaber@...sh.net, mcarlson@...adcom.com, mchan@...adcom.com,
netdev@...r.kernel.org, peter.p.waskiewicz.jr@...el.com,
rdreier@...co.com, Robert.Olsson@...a.slu.se,
shemminger@...ux-foundation.org, sri@...ibm.com, tgraf@...g.ch,
xma@...ibm.com
Subject: Re: [PATCH 0/9 Rev3] Implement batching skb API and support in IPoIB
David Miller wrote:
> From: John Heffner <jheffner@....edu>
> Date: Sun, 26 Aug 2007 21:32:26 -0400
>
>
>>There are a few interesting things here. For one, the bursts caused by
>>TSO seem to be causing the receiver to do stretch acks. This may have a
>>negative impact on flow performance, but it's hard to say for sure how
>>much. Interestingly, it will even further reduce the CPU load on the
>>sender, since it has to process fewer acks.
>>
>>As I suspected, in the non-TSO case the receiver gets lots of packets
>>directly queued to user. This should result in somewhat lower CPU
>>utilization on the receiver. I don't know if it can account for all the
>>difference you see.
>
>
> I had completely forgotten these stretch ACK and ucopy issues.
ISTR that LRO will induce stretch ACKs as well. Not that I dislike fewer ACKs
mind you... :)
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
Powered by blists - more mailing lists