RE: [PATCH] NET: Multiqueue network device support.

[jamal <hadi@cyberus.ca>]

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