[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1191852320.4352.73.camel@localhost>
Date: Mon, 08 Oct 2007 10:05:20 -0400
From: jamal <hadi@...erus.ca>
To: Evgeniy Polyakov <johnpol@....mipt.ru>
Cc: David Miller <davem@...emloft.net>, krkumar2@...ibm.com,
herbert@...dor.apana.org.au, kaber@...sh.net,
shemminger@...ux-foundation.org, jagana@...ibm.com,
Robert.Olsson@...a.slu.se, rick.jones2@...com, xma@...ibm.com,
gaagaan@...il.com, netdev@...r.kernel.org, rdreier@...co.com,
peter.p.waskiewicz.jr@...el.com, mcarlson@...adcom.com,
jeff@...zik.org, mchan@...adcom.com, general@...ts.openfabrics.org,
kumarkr@...ux.ibm.com, tgraf@...g.ch, randy.dunlap@...cle.com,
sri@...ibm.com
Subject: Re: [PATCHES] TX batching
On Mon, 2007-08-10 at 16:51 +0400, Evgeniy Polyakov wrote:
> it looks like you and Krishna use the same requeueing methods - get one
> from qdisk, queue it into blist, get next from qdisk, queue it,
> eventually start transmit, where you dequeue it one-by-one and send (or
> prepare and commit). This is not the 100% optimal approach, but if you
> proved it does not hurt usual network processing, it is ok.
There are probably other bottlenecks that hide the need to optimize
further.
> Number of comments dusted to very small - that's a sign, but I'm a bit
> lost - did you and Krishna create the competing approaches, or they can
> co-exist together, in the former case I doubt you can push, until all
> problematic places are resolved, in the latter case, this is probably
> ready.
Thanks. I would like to make one more cleanup and get rid of the
temporary pkt list in qdisc restart; now that i have defered the skb
pre-format interface it is unnecessary. I have a day off today, so i
will make changes, re-run tests and post again.
I dont see something from Krishna's approach that i can take and reuse.
This maybe because my old approaches have evolved from the same path.
There is a long list but as a sample: i used to do a lot more work while
holding the queue lock which i have now moved post queue lock; i dont
have any speacial interfaces/tricks just for batching, i provide hints
to the core of how much the driver can take etc etc. I have offered
Krishna co-authorship if he makes the IPOIB driver to work on my
patches, that offer still stands if he chooses to take it.
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