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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1181348671.4056.14.camel@localhost>
Date:	Fri, 08 Jun 2007 20:24:31 -0400
From:	jamal <hadi@...erus.ca>
To:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Cc:	Krishna Kumar2 <krkumar2@...ibm.com>,
	Sridhar Samudrala <sri@...ibm.com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	David Miller <davem@...emloft.net>, jeff@...zik.org,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>, kaber@...sh.net,
	netdev@...r.kernel.org
Subject: RE: [PATCH] NET: Multiqueue network device support.

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html