From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 16:09:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD18BD7C for ; Thu, 17 Jan 2013 16:09:00 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm35-vm0.bullet.mail.ne1.yahoo.com (nm35-vm0.bullet.mail.ne1.yahoo.com [98.138.229.96]) by mx1.freebsd.org (Postfix) with ESMTP id 922A9AB3 for ; Thu, 17 Jan 2013 16:09:00 +0000 (UTC) Received: from [98.138.90.49] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jan 2013 16:08:52 -0000 Received: from [98.138.89.192] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jan 2013 16:08:52 -0000 Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 17 Jan 2013 16:08:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 659372.29399.bm@omp1050.mail.ne1.yahoo.com Received: (qmail 70523 invoked by uid 60001); 17 Jan 2013 16:08:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358438932; bh=vzjtEm9Rj88WFZVT/PObedljCRTy/k8/eu32HVc3s2U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nJ4SyJVy9qJCP2K3bpOcl3W7tJ0lS8im/9bcmrgcZjLpPtSRbmVn4NPfppCHLAwWlZmsEdvU1e/urbsMg7eI/zqmIkAt3mPMc6zC82RXvY8VKawLcNwEyJOYbjRgKyu+sJkf8ya0xUt3KIYoL1/G2OoWsUfUHj2ejE6muqm1spM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LkEi8KW/2h2S4ubVZ40e67v6bx3kkm9CaudTU/DFKOFDsuDZBFpT3aHf+kVJfCRD9H0W/YuBIoFWthaqwjEsnYWZLiyuOqIwdzkfy1Zn7nI9n5U2yABSWpTlX0R5s8R9FJuKZPQHbjMogTHKnhzUscMcoNYCohx24F9BWwCQHiM=; X-YMail-OSG: 12bo4XQVM1mvY.IV63tXkb5BR8pwRlhHHd1UBjcgZAHIor8 wC2VAcsZjsXNjZZGFRuaUfyMjMy4RxkCpAwzxJpwA4U9rN5Evy8Ndr5er7VG 7TCznlob3amOIYX7HfWrM2ppAOhLCIwgOycr7_i185mFANjnYdTS6axYFwgd STzpEXLRyxgHiZpJqA1Ex2yKXWEsAOP5UT.JdCfexTTJsWcjCCkCtiKJH4lh hbxpnSNSJ6aq2tLMyLGvn3kTHVa7mwPSNSUKUOJhJlG.xAA8mOs5UQM5VcQB 2l0nGHVWZWJV9O9BzN8vtoNUOxPMHpN42sZjmWsgF.Nu_FOkbz7ABX0mQEok QirVj6YK2Zdmb26x.4XjieCMP5iJWvHWi0cxEq8iiu1IV6nPIJH.g4jCqZRF _yA6gR2ioYTQtJ700u7bjfIddNTuCePRHJq9mSqpOA3SGFUOCRH1N2vOGWfZ oUGngibOak2vMprebn5rZ_V6Fr3tse_EEuoi5f96_6_7esCUI4nZDfQfChoq LRs0P9eFQZTza3OL7SwaMUf1SObNQ Received: from [174.48.128.27] by web121601.mail.ne1.yahoo.com via HTTP; Thu, 17 Jan 2013 08:08:52 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBXZWQsIDEvMTYvMTMsIEx1aWdpIFJpenpvIDxyaXp6b0BpZXQudW5pcGkuaXQ.IHdyb3RlOg0KDQo.IEZyb206IEx1aWdpIFJpenpvIDxyaXp6b0BpZXQudW5pcGkuaXQ.DQo.IFN1YmplY3Q6IFJlOiB0d28gcHJvYmxlbXMgaW4gZGV2L2UxMDAwL2lmX2xlbS5jOjpsZW1faGFuZGxlX3J4dHgoKQ0KPiBUbzogIkJhcm5leSBDb3Jkb2JhIiA8YmFybmV5X2NvcmRvYmFAeWFob28uY29tPg0KPiBDYzogZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcNCj4gRGF0ZTogV2VkbmVzZGF5LCBKYW51YXJ5IDEBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358438932.56236.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Thu, 17 Jan 2013 08:08:52 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Luigi Rizzo In-Reply-To: <20130117025502.GA57613@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:09:00 -0000 --- On Wed, 1/16/13, Luigi Rizzo wrote: > From: Luigi Rizzo > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org > Date: Wednesday, January 16, 2013, 9:55 PM > On Wed, Jan 16, 2013 at 06:19:01AM > -0800, Barney Cordoba wrote: > > > > > > --- On Tue, 1/15/13, Luigi Rizzo > wrote: > > > > > From: Luigi Rizzo > > > Subject: two problems in > dev/e1000/if_lem.c::lem_handle_rxtx() > > > To: head@freebsd.org, > "freebsd-net@freebsd.org" > > > > Cc: "Jack Vogel" > > > Date: Tuesday, January 15, 2013, 8:23 PM > > > Hi, > > > i found a couple of problems in > > > ? ? ? ? > > > dev/e1000/if_lem.c::lem_handle_rxtx() , > > > (compare with dev/e1000/if_em.c::em_handle_que() > for better > > > understanding): > > > > > > 1. in if_em.c::em_handle_que(), when em_rxeof() > exceeds the > > > ? rx_process_limit, the task is rescheduled so it > can > > > complete the work. > > > ? Conversely, in if_lem.c::lem_handle_rxtx() the > > > lem_rxeof() is > > > ? only run once, and if there are more pending > packets > > > the only > > > ? chance to drain them is to receive (many) more > > > interrupts. > > > > > > ? This is a relatively serious problem, because > the > > > receiver has > > > ? a hard time recovering. > > > > > > ? I'd like to commit a fix to this same as it is > done > > > in e1000. > > > > > > 2. in if_em.c::em_handle_que(), interrupts are > reenabled > > > unconditionally, > > > ???whereas lem_handle_rxtx() only enables > > > them if IFF_DRV_RUNNING is set. > > > > > > ???I cannot really tell what is the correct > > > way here, so I'd like > > > ???to put a comment there unless there is a > > > good suggestion on > > > ???what to do. > > > > > > ???Accesses to the intr register are > > > race-prone anyways > > > ???(disabled in fastintr, enabled in the rxtx > > > task without > > > ???holding any lock, and generally accessed > > > under EM_CORE_LOCK > > > ???in other places), and presumably > > > enabling/disabling the > > > ???interrupts around activations of the taks > > > is just an > > > ???optimization (and on a VM, it is actually > > > a pessimization > > > ???due to the huge cost of VM exits). > > > > > > cheers > > > luigi > > > > This is not really a big deal; this is how things works > for a million > > years before we had task queues. > > i agree that the second issue is not a big deal. > > The first one, on the contrary, is a real problem no matter > how you set the 'work' parameter (unless you make it large > enough to drain the entire queue in one call). Which should be the goal, except in extreme circumstances. Having more packets than "work" should be the extreme case and not the norm. All work should do is normalize bursts of packets. If you're consistently over work then either your work parameter is too low, or your interrupt moderation is too wide. Adding a cleanup task simply compensates for bad tuning. BC