Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Nov 2012 09:30:04 +0100
From:      Andre Oppermann <andre@freebsd.org>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        Barney Cordoba <barney_cordoba@yahoo.com>, Jim Thompson <jim@netgate.com>, Alfred Perlstein <bright@mu.org>, khatfield@socllc.net, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: FreeBSD boxes as a 'router'...
Message-ID:  <50AC910C.4030004@freebsd.org>
In-Reply-To: <CAJ-VmomCxSzTzwi8QxzW8_%2BaMT2DnmRxSGaau=1RWFGP8XBmMQ@mail.gmail.com>
References:  <1353448328.76219.YahooMailClassic@web121602.mail.ne1.yahoo.com> <E1F4816E-676C-4630-9FA1-817F737D007D@netgate.com> <50AC08EC.8070107@mu.org> <832757660.33924.1353460119408@238ae4dab3b4454b88aea4d9f7c372c1.nuevasync.com> <CAJ-Vmok8Ybdi%2BY8ZguMTKC7%2BF5=OxVDog27i4UgY-s3MCZkGcQ@mail.gmail.com> <250266404.35502.1353464214924@238ae4dab3b4454b88aea4d9f7c372c1.nuevasync.com> <50AC8393.3060001@freebsd.org> <CAJ-VmomCxSzTzwi8QxzW8_%2BaMT2DnmRxSGaau=1RWFGP8XBmMQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 21.11.2012 08:55, Adrian Chadd wrote:
> Something that has popped up a few times, even recently, is breaking
> out of an RX loop after you service a number of frames.

That is what I basically described.

> During stupidly high levels of RX, you may find the NIC happily
> receiving frames faster than you can service the RX queue. If this
> occurs, you could end up just plain being stuck there.

That's the live-lock.

> So what I've done in the past is to loop over a certain number of
> frames, then schedule a taskqueue to service whatever's left over.

Taskqueue's shouldn't be used anymore.  We've got ithreads now.
Contrary to popular belief (and due to poor documentation) an
ithread does not run at interrupt level.  Only the fast interrupt
handler does that.  The ithread is a normal kernel thread tied to
an fast interrupt handler and trailing it whenever it said
INTR_SCHEDULE_ITHREAD.

> I've also had to do some proactive frame dropping at the driver layer
> when under ridiculous levels of RX load, but that's a different story.

That's the CoDel stuff I mentioned where it tries to drop frames in
a fair manner.

> I wonder how many drivers break out of an RX loop after a fixed amount of time..

Most.  The problem seems to be that the taskqueue runs at high priority
effectively starving out other threads/processes again.

-- 
Andre




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50AC910C.4030004>