netdev
[Top] [All Lists]

Re: LLTX and netif_stop_queue

To: Eric Lemoine <eric.lemoine@xxxxxxxxx>
Subject: Re: LLTX and netif_stop_queue
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Thu, 23 Dec 2004 17:37:24 +0100
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, hadi@xxxxxxxxxx, roland@xxxxxxxxxxx, netdev@xxxxxxxxxxx, openib-general@xxxxxxxxxx
In-reply-to: <5cac192f0412230110628749e3@xxxxxxxxxxxxxx>
References: <52llbwoaej.fsf@xxxxxxxxxxx> <20041217214432.07b7b21e.davem@xxxxxxxxxxxxx> <1103484675.1050.158.camel@xxxxxxxxxxxxxxxx> <5cac192f04122210491d64d4b6@xxxxxxxxxxxxxx> <20041222202919.057b8331.davem@xxxxxxxxxxxxx> <5cac192f0412230110628749e3@xxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5
Eric Lemoine wrote:
I still have one concern with the LLTX code (and it may be that the
correct patch is Jamal's) :

Without LLTX we do : lock(queue_lock), lock(xmit_lock),
release(queue_lock), release(xmit_lock). With LLTX (without Jamal's
patch) we do : lock(queue_lock), release(queue_lock), lock(tx_lock),
release(tx_lock). LLTX doesn't look correct because it creates a race
condition window between the the two lock-protected sections. So you
may want to reconsider Jamal's patch or pull out LLTX...

You're right, it can cause packet reordering if something like this
happens:

CPU1                    CPU2
lock(queue_lock)        
dequeue
unlock(queue_lock)
                        lock(queue_lock)
                        dequeue
                        unlock(queue_lock)
                        lock(xmit_lock)
                        hard_start_xmit
                        unlock(xmit_lock)
lock(xmit_lock)
hard_start_xmit
unlock(xmit_lock)

Jamal's patch should fix this.

Regards
Patrick

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