Date: Fri, 18 Jan 2013 12:09:21 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Barney Cordoba <barney_cordoba@yahoo.com> Cc: freebsd-net@freebsd.org, Luigi Rizzo <rizzo@iet.unipi.it> Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <CAJ-Vmo=Lxyxi5-QEKLpqwHX2DjGw%2B-mo4_7T=i5cZZs84faOYA@mail.gmail.com> In-Reply-To: <1358519416.46817.YahooMailClassic@web121606.mail.ne1.yahoo.com> References: <CAJ-VmonmUrFXwUZ0A=yYYzoJbjCvHKuo%2BTEtTwFP5D7RGnKmKA@mail.gmail.com> <1358519416.46817.YahooMailClassic@web121606.mail.ne1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 January 2013 06:30, Barney Cordoba <barney_cordoba@yahoo.com> wrote: > 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. The problem with interrupt moderation combined with enabling/disabling interrupts is that if you get it even slightly wrong, you won't run the packet processing thread(s) until the next interrupt occurs - even if something is in the queue. There's been a class of bugs in the em driver that resemble this. Same as what I found in ath(4) - even the TX watchdog code is broken like this :( Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=Lxyxi5-QEKLpqwHX2DjGw%2B-mo4_7T=i5cZZs84faOYA>