[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1187906650.4279.16.camel@localhost>
Date: Thu, 23 Aug 2007 18:04:10 -0400
From: jamal <hadi@...erus.ca>
To: David Miller <davem@...emloft.net>
Cc: rick.jones2@...com, 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, kumarkr@...ux.ibm.com, 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
On Wed, 2007-22-08 at 13:21 -0700, David Miller wrote:
> From: Rick Jones <rick.jones2@...com>
> Date: Wed, 22 Aug 2007 10:09:37 -0700
>
> > Should it be any more or less worrysome than small packet
> > performance (eg the TCP_RR stuff I posted recently) being rather
> > worse with TSO enabled than with it disabled?
>
> That, like any such thing shown by the batching changes, is a bug
> to fix.
Possibly a bug - but you really should turn off TSO if you are doing
huge interactive transactions (which is fair because there is a clear
demarcation).
The litmus test is the same as any change that is supposed to improve
net performance - it has to demonstrate it is not intrusive and that it
improves (consistently) performance. The standard metrics are
{throughput, cpu-utilization, latency} i.e as long as one improves and
others remain zero, it would make sense. Yes, i am religious for
batching after all the invested sweat (and i continue to work on it
hoping to demystify) - the theory makes a lot of sense.
cheers,
jamal
-
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