| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: LLTX and netif_stop_queue, jamal |
|---|---|
| Next by Date: | Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier., jamal |
| Previous by Thread: | Re: LLTX and netif_stop_queue, jamal |
| Next by Thread: | Re: LLTX and netif_stop_queue, Roland Dreier |
| Indexes: | [Date] [Thread] [Top] [All Lists] |