On Fri, 2007-08-06 at 12:55 -0700, Waskiewicz Jr, Peter P wrote:
> > I thought the correct use is to get this lock on clean_tx
> > side which can get called on a different cpu on rx (which
> > also cleans up slots for skbs that have finished xmit). Both
> > TX and clean_tx uses the same tx_ring's head/tail ptrs and
> > should be exclusive. But I don't find clean tx using this
> > lock in the code, so I am confused :-)
>
> >From e1000_main.c, e1000_clean():
>
> /* e1000_clean is called per-cpu. This lock protects
> * tx_ring[0] from being cleaned by multiple cpus
> * simultaneously. A failure obtaining the lock means
> * tx_ring[0] is currently being cleaned anyway. */
> if (spin_trylock(&adapter->tx_queue_lock)) {
> tx_cleaned = e1000_clean_tx_irq(adapter,
> &adapter->tx_ring[0]);
> spin_unlock(&adapter->tx_queue_lock);
> }
Are you saying theres no problem because the adapter->tx_queue_lock is
being held?
> In a multi-ring implementation of the driver, this is wrapped with for
> (i = 0; i < adapter->num_tx_queues; i++) and &adapter->tx_ring[i]. This
> lock also prevents the clean routine from stomping on xmit_frame() when
> transmitting. Also in the multi-ring implementation, the tx_lock is
> pushed down into the individual tx_ring struct, not at the adapter
> level.
That sounds right - but the adapter lock is not related to tx_lock in
current e1000, correct?
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
