[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OF0002C3DB.2E4C4A38-ON88257341.005B1253-88257341.005C7C2A@us.ibm.com>
Date: Fri, 24 Aug 2007 09:50:58 -0700
From: David Stevens <dlstevens@...ibm.com>
To: Stephen Hemminger <shemminger@...ux-foundation.org>
Cc: akepner@....com, linux-kernel <linux-kernel@...r.kernel.org>,
linux-ppc <linuxppc-dev@...abs.org>,
Marcus Eder <meder@...ibm.com>,
netdev <netdev@...r.kernel.org>, netdev-owner@...r.kernel.org,
Jan-Bernd Themann <ossthema@...ibm.com>,
Christoph Raisch <raisch@...ibm.com>,
Stefan Roscher <stefan.roscher@...ibm.com>,
Jan-Bernd Themann <themann@...ibm.com>,
Thomas Klein <tklein@...ibm.com>
Subject: Re: RFC: issues concerning the next NAPI interface
Stephen Hemminger <shemminger@...ux-foundation.org> wrote on 08/24/2007
08:52:03 AM:
>
> You need hardware support for deferred interrupts. Most devices have it
> (e1000, sky2, tg3)
> and it interacts well with NAPI. It is not a generic thing you want done
by the stack,
> you want the hardware to hold off interrupts until X packets or Y usecs
have expired.
For generic hardware that doesn't support it, couldn't you use an
estimater
and adjust the timer dynamicly in software based on sampled values? Switch
to per-packet
interrupts when the receive rate is low...
Actually, that's how I thought NAPI worked before I found out
otherwise (ie,
before I looked :-)).
The hardware-accelerated one is essentially siloing as done by
ancient serial
devices on UNIX systems. If you had a tunable for a target count, and an
estimator
for the time interval, then switch to per-packet when the estimator
exceeds a tunable
max threshold (and also, I suppose, if you near overflowing the ring on
the min
timer granularity), you get almost all of it, right?
Problem is if it increases rapidly, you may drop packets before
you notice
that the ring is full in the current estimated interval.
+-DLS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists