Re: [sungem] proposal for a new locking strategy

[Stephen Hemminger <shemminger@osdl.org>]

O
> > > > But the spin is still there, just more complex..
> > > > In qdisc_restart() processing of NETDEV_TX_LOCKED causes:
> > > >         spin_lock(dev->xmit_lock)
> > > >
> > > >         q->requeue()
> > > >         netif_schedule(dev);
> > > >
> > > > SOFTIRQ:
> > > >         net_tx_action()
> > > >         qdisc_run() --> qdisc_restart()
> > > >
> > > > So instead of spinning in tight loop, you end up with a longer code
> > > > path.
> > >
> > > Stephen, sorry for insisting a bit but I'm failing to see how B is
> > > different from C in that respect. With method B, in qdisc_restart(),
> > > if netif_tx_trylock() fails to acquire the lock then we also
> > > requeue(), etc. Same long code path in case of contention.
> > >
> >
> > Method C LLTX causes repeated softirq's which will be slower since the loop
> > requires more instructions than a simple spin loop (Method B).
> 
> What I'm saying above is that Method B also causes repeated tx
> softirqs in case of contention on netif_tx_lock. The code path is :
> netif_tx_trylock() fails -> requeue() -> netif_schedule() ->
> raise_softirq(NET_TX_SOFTIRQ). Am I missing anything?
> 

Never mind, you right.  I think the netif_tx_trylock() there is a bad
idea because of the long route as shown.  Trylock's are usually bad SMP
design anyway. Not sure if it would be possible to change the locking
in qdisc_restart() without causing collateral damage in network drivers.


-- 
Stephen Hemminger <shemminger@osdl.org>