Date: Fri, 18 Jan 2013 06:35:04 -0800 (PST) From: Barney Cordoba <barney_cordoba@yahoo.com> To: Luigi Rizzo <rizzo@iet.unipi.it>, Adrian Chadd <adrian@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <1358519704.98312.YahooMailClassic@web121605.mail.ne1.yahoo.com> In-Reply-To: <CAJ-VmomAfCOzv%2Bb_N-6j2xWvdmpX9O7Qu5S_E=5XG3fRj=U9Vg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- On Thu, 1/17/13, Adrian Chadd <adrian@freebsd.org> wrote: > From: Adrian Chadd <adrian@freebsd.org> > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Luigi Rizzo" <rizzo@iet.unipi.it> > Cc: "Barney Cordoba" <barney_cordoba@yahoo.com>, freebsd-net@freebsd.org > Date: Thursday, January 17, 2013, 2:04 PM > On 17 January 2013 09:44, Luigi Rizzo > <rizzo@iet.unipi.it> > wrote: >=20 > > (in the "lem" driver this cannot happen until you > release some > > rx slots, which only happens once at the end of the > lem_rxeof() routine, > > not long before re-enabling interrupts) >=20 > Right. >=20 > >> * .. and the hardware immediately sends you the MSI > or signals an interrupt; > >> * .. thus you re-enter the RX processing thread > almost(!) immediately. > > > > the problem i was actually seeing are slightly > different, namely: > > - once the driver lags behind, it does not have a > chance to recover > >=A0=A0=A0even if there are CPU cycles > available, because both interrupt > >=A0=A0=A0rate and packets per interrupt are > capped. >=20 > Right, but the interrupt isn't being continuously asserted > whilst > there are packets there. > You just get a single interrupt when the queue has frames in > it, and > you won't get a further interrupt for whatever the > mitigation period > is (or ever, if you fill up the RX FIFO, right?) >=20 > > - much worse, once the input stream stops, you have a > huge backlog that > >=A0=A0=A0is not drained. And if, say, you try > to ping the machine, > >=A0=A0=A0the incoming packet is behind another > 3900 packets, so the first > >=A0=A0=A0interrupt drains 100 (but not the ping > request, so no response), > >=A0=A0=A0you keep going for a while, eventually > the external world sees the > >=A0=A0=A0machine as not responding and stops > even trying to talk to it. >=20 > Right, so you do need to do what you're doing - but I still > think > there's a possibility of a race there. > Namely that your queue servicing does reach the end of the > list (and > so you don't immediately reschedule the taskqueue) but some > more > frames have arrived. > You have to wait for the next mitigated interrupt for that. i don't think that's the case. The mitigation is a minimum delay. If the=20 delay is longer than the minimum, you'd get an interrupt as soon as you enable it, which is clearly better than scheduling a task. BC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358519704.98312.YahooMailClassic>