From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 14:30:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36095133 for ; Fri, 18 Jan 2013 14:30:48 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm20-vm5.bullet.mail.ne1.yahoo.com (nm20-vm5.bullet.mail.ne1.yahoo.com [98.138.91.242]) by mx1.freebsd.org (Postfix) with ESMTP id EB865B09 for ; Fri, 18 Jan 2013 14:30:47 +0000 (UTC) Received: from [98.138.90.57] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:40 -0000 Received: from [98.138.87.10] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:40 -0000 Received: from [127.0.0.1] by omp1010.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:40 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 437099.29022.bm@omp1010.mail.ne1.yahoo.com Received: (qmail 92146 invoked by uid 60001); 18 Jan 2013 14:30:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358519440; bh=Nu7pTW4v/J5nMIohhxuwGv8bTUBis0K5WDRr5itZgpg=; 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=ctFg64m4r2Grb08W6o7Kn6x/swgDFaMdbd7UtPOUEU++ZYkJNP/oe7WtWp4FUZOUTW9eDq+/0NV6SMsKIPEgFRnRB6DUz/MD4TAGodgusNmEP1+e6cozc5htRsfyRVkj2nNA+cK8QTdxEFpsofJfvh87NB74UIj+6KS/gOH5Ydg= 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=r3XUcdJWfqjkbmz6N6h+jTOw3tmQU6BvTdmFbGXoK7XhycMuYYlL1aiHxGTvxFms0/YuOwCvS2liFcvVAOyYGkNVeuoNQZAbrNzU4Y2JtUY7ZtsPJ6JifNsPqKStZRP9bSyou4VHf/psYdqr/Eu/QoEGr40k9BFb5wvQ9gMeOHs=; X-YMail-OSG: m4rxVdQVM1nmDWZvtuEEj.O62_VVFaFtIzC.Xmkr4YMykPh 098BGPQlsyp5WZYDGQeXzUp5VTmiCxZ7iicZaVpWME.f7hP_n.hFVOXKfIMC AlbSME46AeBtaLBcWzs9RQBbp98Qq7Do0ltl1v.EvJQDBh1t73f49LOw2769 5EJcFm8IBEGfOMIB99_dd.p2IS7aTvtxvIkdpMRFFgzMo3NxB088r7F05bC0 eB3OQut2oKq62jNushnPk7kRvtRaOTyLID41oHCdkAAopxcW1gC2RCwDtT1k 8SjWMfJNnTqlQVvk.YHAVU8sguwYjx1BfrrpsuyczRIUJay.OmKGdTut_l1V DBIuY9.Pf8RvWhm1_D.638mKvGFBrGLREvt5suZQw.bsH7gmJelgqFgqyflQ i6tWMgK03_TVPvIvYMAtKuzXbn_I_O9o1f3yzyz.XM488HUZJxJKjJo3jKKy a_VR.kW.ALpDDIsDjYc1D9T3kkyFamwuc5URYXZDnGISt5xjUtXMLklh1hGC yCmQNKQszSxnExi0ym3HoEcsxc1xS Received: from [174.48.128.27] by web121605.mail.ne1.yahoo.com via HTTP; Fri, 18 Jan 2013 06:30:40 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBUaHUsIDEvMTcvMTMsIEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPiB3cm90ZToNCg0KPiBGcm9tOiBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4NCj4gU3ViamVjdDogUmU6IHR3byBwcm9ibGVtcyBpbiBkZXYvZTEwMDAvaWZfbGVtLmM6OmxlbV9oYW5kbGVfcnh0eCgpDQo.IFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.DQo.IENjOiAiTHVpZ2kgUml6em8iIDxyaXp6b0BpZXQudW5pcGkuaXQ.LCBmcmVlYnNkLW5ldEBmcmUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358519440.88044.YahooMailClassic@web121605.mail.ne1.yahoo.com> Date: Fri, 18 Jan 2013 06:30:40 -0800 (PST) From: Barney Cordoba Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() To: Adrian Chadd In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, Luigi Rizzo 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: Fri, 18 Jan 2013 14:30:48 -0000 --- On Thu, 1/17/13, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" > Cc: "Luigi Rizzo" , freebsd-net@freebsd.org > Date: Thursday, January 17, 2013, 11:48 AM > There's also the subtle race > condition in TX and RX handling that > re-queuing the taskqueue gets around. > > Which is: > > * The hardware is constantly receiving frames , right until > you blow > the FIFO away by filling it up; > * The RX thread receives a bunch of frames; > * .. and processes them; > * .. once it's done processing, the hardware may have read > some more > frames in the meantime; > * .. and the hardware may have generated a mitigated > interrupt which > you're ignoring, since you're processing frames; > * So if your architecture isn't 100% paranoid, you may end > up having > to wait for the next interrupt to handle what's currently in > the > queue. > > Now if things are done correct: > > * The hardware generates a mitigated interrupt > * The mask register has that bit disabled, so you don't end > up receiving it; > * You finish your RX queue processing, and there's more > stuff that's > appeared in the FIFO (hence why the hardware has generated > another > mitigated interrupt); > * You unmask the interrupt; > * .. and the hardware immediately sends you the MSI or > signals an interrupt; > * .. thus you re-enter the RX processing thread almost(!) > immediately. > > However as the poster(s) have said, the interrupt > mask/unmask in the > intel driver(s) may not be 100% correct, so you're going to > end up > with situations where interrupts are missed. > > The reason why this wasn't a big deal in the deep/distant > past is > because we didn't used to have kernel preemption, or > multiple kernel > threads running, or an overly aggressive scheduler trying > to > parallelise things as much as possible. A lot of > net80211/ath bugs > have popped out of the woodwork specifically because of the > above > changes to the kernel. They were bugs before, but people > didn't hit > them. > I don't see the distinction between the rx thread getting re-scheduled "immediately" vs introducing another thread. In fact you increase missed interrupts by this method. The entire point of interrupt moderation is to tune the intervals where a driver is processed. You might as well just not have a work limit and process until your done. The idea that "gee, I've been taking up too much cpu, I'd better yield" to just queue a task and continue soon after doesn't make much sense to me. BC