From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 14:30:23 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 1FD3677 for ; Fri, 18 Jan 2013 14:30:23 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm33-vm8.bullet.mail.ne1.yahoo.com (nm33-vm8.bullet.mail.ne1.yahoo.com [98.138.229.72]) by mx1.freebsd.org (Postfix) with ESMTP id D3F85AFC for ; Fri, 18 Jan 2013 14:30:22 +0000 (UTC) Received: from [98.138.90.51] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:16 -0000 Received: from [98.138.89.254] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:16 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 14:30:16 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 826768.88800.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 56221 invoked by uid 60001); 18 Jan 2013 14:30:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358519416; 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=X6OFCrtA3nRxsTBv72WiLWhCLps5BcdNnSkgPI0twjhTzLtnJCD16cnIIE1JlidR0OnGlBFNWUTXrvdIRxrqzvUScGx08GHwuwZ6G/8MOoSzCriPxeEkyE70lmvmEuP8dZao86mdrgSxus49ougG9WicfcL88NbfQdBG/l9V1Ok= 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=hpyMMPcbnzQe0LxY0T5PK2+wvkCAXO236ZrJKQqCj7gpRO7rlbwvW/xnyik+4cG01U9zZgmxTh6hMBlN/RcOgzHHkakuZSfIxwjf/ZzEXAq4lhUSu7X66n3DO/zTGNAeCyuA0BxF4AuxkoLyFS0pgDq3hfk/bYqv3RlA9zD5yMY=; X-YMail-OSG: NwpVQmcVM1lIVtqyA7Gtoczv2ItKBvbY7orjayA75WGYkQA 9MRagQFGS7GTa9sDAG7DOxzeTIiaobXXePn7tQKmi.WTZfxO_fBxHZaEiFVW iwTzCplMz8YhYVJNTBmXQvjQsyqV_Jo9VwAoqyGyuxfaDhQJ78FPcF06yNYA ilMvAkLZ5xfvd5WKkz00Thz50XwwpUWVNJsITcEqGmtbRKKZehCIFa5xgFeL PbSO_amomai7KINKW2bgZvm4DhDTuxp_f_y_GsSwg4XLPWZZZRR6V6kIfj31 8dU810V1cXlDwBlejtowX3GgP9UzKuPAZdPl8pEl_IlEm8dax7MB1IxEuzn2 lsTBjJZyJsTbJfyClyudg00k5sVcCsu1qJsmVtFDnLb.gZ1kEE2.I60vVHgM C4FY16QieaaCB.H5PStG495DmBhXQPx_v9lJHGGjYMQezHbmQtgoVVsGWr9x fvHautLKZCZu.QzpJwDlN2huuLuffAefOUqzjlvQS_N83Gdz1BuV77BeMLfz E38NfWMCYjFWy2u9lCRcLg9JgIHgG Received: from [174.48.128.27] by web121606.mail.ne1.yahoo.com via HTTP; Fri, 18 Jan 2013 06:30:16 PST X-Rocket-MIMEInfo: 001.001, DQoNCi0tLSBPbiBUaHUsIDEvMTcvMTMsIEFkcmlhbiBDaGFkZCA8YWRyaWFuQGZyZWVic2Qub3JnPiB3cm90ZToNCg0KPiBGcm9tOiBBZHJpYW4gQ2hhZGQgPGFkcmlhbkBmcmVlYnNkLm9yZz4NCj4gU3ViamVjdDogUmU6IHR3byBwcm9ibGVtcyBpbiBkZXYvZTEwMDAvaWZfbGVtLmM6OmxlbV9oYW5kbGVfcnh0eCgpDQo.IFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.DQo.IENjOiAiTHVpZ2kgUml6em8iIDxyaXp6b0BpZXQudW5pcGkuaXQ.LCBmcmVlYnNkLW5ldEBmcmUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358519416.46817.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Fri, 18 Jan 2013 06:30:16 -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:23 -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