[ofa-general] Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock

[Stephen Hemminger]

On Tue, 25 Sep 2007 09:15:38 -0400
jamal <hadi at cyberus.ca> wrote:

> 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.
> 

http://en.wikipedia.org/wiki/Monitor_(synchronization)
> What do you mean it is "more of a monitor"?

The transmit code path is locked as a code region, rather than just object locking
on the transmit queue or other fine grained object. This leads to moderately long
lock hold times when multiple qdisc's and classification is being done.

> 
> 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.

If we went to finer grain locking it would also mean changes to all network
devices using the new locking model. My assumption is that we would use
something like the features flag to do the transition for backward compatibility.

Take this as a purely "what if" or "it would be nice if" kind of suggestion
not a requirement or some grand plan.


-- 
Stephen Hemminger <shemminger at linux-foundation.org>