netdev
[Top] [All Lists]

Re: LLTX and netif_stop_queue

To: hadi@xxxxxxxxxx
Subject: Re: LLTX and netif_stop_queue
From: Eric Lemoine <eric.lemoine@xxxxxxxxx>
Date: Mon, 3 Jan 2005 16:48:00 +0100
Cc: Andi Kleen <ak@xxxxxxx>, Patrick McHardy <kaber@xxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, roland@xxxxxxxxxxx, netdev@xxxxxxxxxxx, openib-general@xxxxxxxxxx
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=bqlWbHnOofEuCNnArW5xjKx8U5HVmqRlvva6gi2Qn6HCXr9CpEDiyA6UYpotEvWgw1TXf58STO33hUvt5mRjRYgRXYYmJSO+Nr2rrR9Kbhq03MAFpllsJyY/HFD6tcSz6tWhDFqmIVJxXSGoeRV0mtcivQuo5hIKuSxj+TMnVoI=
In-reply-to: <1104764660.1048.578.camel@xxxxxxxxxxxxxxxx>
References: <52llbwoaej.fsf@xxxxxxxxxxx> <1103484675.1050.158.camel@xxxxxxxxxxxxxxxx> <5cac192f04122210491d64d4b6@xxxxxxxxxxxxxx> <20041222202919.057b8331.davem@xxxxxxxxxxxxx> <5cac192f0412230110628749e3@xxxxxxxxxxxxxx> <41CAF444.3000305@xxxxxxxxx> <5cac192f04122408102129af43@xxxxxxxxxxxxxx> <1104240717.1100.66.camel@xxxxxxxxxxxxxxxx> <5cac192f0501021530672a908a@xxxxxxxxxxxxxx> <1104764660.1048.578.camel@xxxxxxxxxxxxxxxx>
Reply-to: Eric Lemoine <eric.lemoine@xxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On 03 Jan 2005 10:04:21 -0500, jamal <hadi@xxxxxxxxxx> wrote:
> this piece:
> -----
> +
> +                       /* And release queue */
> +                       spin_unlock(&dev->queue_lock);
>                 }
> ---------
> 
> Isnt there a possibility (higher as you increase number of processors)
> that you will spin for a long time in _the driver_ waiting for the queue
> lock?

I don't see how LLTX is different from non-LLTX wrt the time spent
spinning on queue_lock. What am i missing?

> 
> Maybe we need a flag "the queue lock" is already been grabbed passed
> to the driver. LLTX is a good  alias but insufficient (if you run your
> driver in an old kernels which support LLTX but not the idea of locking
> the queue for you).
> 
> Andi or anyone else - has anyone really done perfomance analysis of LLTX
> (with anything other than loopback) and shown it has any value? Maybe
> time to just shoot the damn thing.

I do not like LLTX too much either as I can't see a cleaner way to get
rid of that packet reordering race condition.

-- 
Eric

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