[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071008125125.GA31456@2ka.mipt.ru>
Date: Mon, 8 Oct 2007 16:51:25 +0400
From: Evgeniy Polyakov <johnpol@....mipt.ru>
To: jamal <hadi@...erus.ca>
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
Hi Jamal.
On Sun, Oct 07, 2007 at 02:34:53PM -0400, jamal (hadi@...erus.ca) wrote:
>
> Please provide feedback on the code and/or architecture.
> Last time i posted them i received little. They are now updated to
> work with the latest net-2.6.24 from a few hours ago.
>
> Patch 1: Introduces batching interface
> Patch 2: Core uses batching interface
> Patch 3: get rid of dev->gso_skb
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.
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.
--
Evgeniy Polyakov
-
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