[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1190726138.4264.105.camel@localhost>
Date: Tue, 25 Sep 2007 09:15:38 -0400
From: jamal <hadi@...erus.ca>
To: Stephen Hemminger <shemminger@...ux-foundation.org>
Cc: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
David Miller <davem@...emloft.net>, krkumar2@...ibm.com,
johnpol@....mipt.ru, herbert@...dor.apana.org.au, kaber@...sh.net,
jagana@...ibm.com, Robert.Olsson@...a.slu.se, rick.jones2@...com,
xma@...ibm.com, gaagaan@...il.com, netdev@...r.kernel.org,
rdreier@...co.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: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
On Mon, 2007-24-09 at 17:14 -0700, Stephen Hemminger wrote:
> Since we are redoing this,
> is there any way to make the whole TX path
> more lockless? The existing model seems to be more of a monitor than
> a real locking model.
What do you mean it is "more of a monitor"?
On the challenge of making it lockless:
About every NAPI driver combines the tx prunning with rx polling. If you
are dealing with tx resources on receive thread as well as tx thread,
_you need_ locking. The only other way we can do avoid it is to separate
the rx path interupts from ones on tx related resources; the last NAPI
driver that did that was tulip; i think the e1000 for a short period in
its life did the same as well. But that has been frowned on and people
have evolved away from 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