Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 18:43:48 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E1hfE1013942 for ; Mon, 13 Sep 2004 18:43:42 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C72M0-00038E-5f for netdev@oss.sgi.com; Mon, 13 Sep 2004 21:43:32 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C72Lw-00038Z-G1; Mon, 13 Sep 2004 21:43:28 -0400 Subject: Re: [PATCH] Fix locking bug in lltx path From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: "David S. Miller" , netdev@oss.sgi.com, arjanv@redhat.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1095126203.1056.7.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Sep 2004 21:43:24 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1820 Lines: 58 Finaly got around to testing today and got bitten by this (was planning to send patch);-> In any case, some good news: one of the NICs tested was e1000 with and without LLTX pure forwarding (eth0->eth1 and eth1->eth0, 64 byte packets beating up the interfaces at 1/48Mpps): did not see much difference between the two. There did seem to be some latency improvements (in the range of 50 microsecs or so for the LLTX but could be experimental error, needs more validation). I think perhaps a case where multi processors fanning into one NIC would be a better test to see the value of LLTX. The good news (for me) is it doesnt seem to affect things negatively. [We saw some corrupt netpoll packets but that could be something else broken]. cheers, jamal On Mon, 2004-09-13 at 14:11, Andi Kleen wrote: > Thanks to Arjan's spinlock debug kernel for finding it. > > This fixes a silly missing spin lock in the relock path. For some > reason it seems to still work when you don't have spinlock debugging > enabled. > > Please apply. > > -Andi > > -------------------------------------------------------------------- > > Fix missing spin lock in lltx path. > > Thanks to Arjan's spinlock debug kernel for finding it. > > Signed-off-by: Andi Kleen > > diff -u linux-2.6.9rc1-bk19/net/sched/sch_generic.c-X linux-2.6.9rc1-bk19/net/sched/sch_generic.c > --- linux-2.6.9rc1-bk19/net/sched/sch_generic.c-X 2004-09-13 08:51:46.000000000 +0200 > +++ linux-2.6.9rc1-bk19/net/sched/sch_generic.c 2004-09-13 19:22:50.000000000 +0200 > @@ -153,8 +153,10 @@ > spin_lock(&dev->queue_lock); > return -1; > } > - if (ret == -1 && nolock) > + if (ret == -1 && nolock) { > + spin_lock(&dev->queue_lock); > goto collision; > + } > } > > /* Release the driver */ > > >