[Top] [All Lists]

Re: Queue and SMP locking discussion (was Re: 3c59x.c)

To: becker@xxxxxxxxx (Donald Becker)
Subject: Re: Queue and SMP locking discussion (was Re: 3c59x.c)
From: kuznet@xxxxxxxxxxxxx
Date: Fri, 31 Mar 2000 21:57:56 +0400 (MSK DST)
Cc: netdev@xxxxxxxxxxx, andrewm@xxxxxxxxxx
In-reply-to: <Pine.LNX.4.10.10003301359200.2499-100000@xxxxxxxxxxxxx> from "Donald Becker" at Mar 30, 0 02:55:26 pm
Sender: owner-netdev@xxxxxxxxxxx

> Yes.  The de facto guide, the existing SMP changes, are inefficient.

Donald, I do not understand you, honestly. Design better scheme. Just do it.
If you have no time to do it, you will have to work in environment,
designed by stupid guys sort of me, who always have lots of time,
unfortunately. It is evident, is not it?

> The tricky part for avoiding further locking is making certain that
> descriptor index entries are integers that may be atomically incremented WRT
> to the Tx queuing.
> In the Tx packet routine
>       entry = tp->cur_tx % TX_RING_SIZE;
> ...  queue a packet to the 'entry' slot
>       tp->cur_tx++;
> In the interrupt (Tx clean-up) routine
>       for (dirty_tx = tp->dirty_tx; tp->cur_tx - dirty_tx > 0; dirty_tx++) {
> This should *not* require locking on any architecture.

If to forget that queue has another end (when it becomes full).
If to remember about this, the sheme becomes more complicated.
All the problems are really there, at the another end.

> What may require locking is when the Tx queue is shared by the Rx filter
> setup logic, as on the Tulip.  The set_rx_mode() code must either be able to
> spin on the Tx queue lock or otherwise have a way to be Tx-serialized.

Top level guarantees that it does not overlap to hard_start_xmit().

> Setting the Rx filter mode is very rare compared to sending packets, so
> adding a new Tx lock for this is a bad design.

Agreed. BTW do you remember the story with eepro100? Why did it fail
doing set_rx_mode() before Torvalds added TX lock there?

> The only reasonable approach is disabling all IRQs or selectively disabling
> one IRQ chain.  The cli() approach used to be very cheap, and is now
> expensive only on SMPs.  Disabling an IRQ chain used to be very expensive,
> and is only slightly less expensive now.  

Not all the devices are DMAing yet. And without DMA cli() is reliable death
of serial interfaces.

> I wasn't naming names..  (And I don't think that you were responsible for
> the original bug, just for not seeing that the semantics that it created
> were unreasonable.)

I simply knew about this bug (experienced on my own skin) long before
this question was raised, managed to ensure myself that it is not a bug,
but feature and tried to propagate this "knowledge". 8)8)


<Prev in Thread] Current Thread [Next in Thread>