David S. Miller writes:
>
> I put my vote there too.
>
> I have no problems with it, as long as we don't horribly break tools
> that parse the values we export now.
>
> BTW, we ought to start thinking about NAPI integration for 2.5.x soon.
> What is the current status of the patches Robert?
First the GIGE router I pointed to runs NAPI since about 3 months with three
e1000's.
I the feel the obstacle for 2.5.x inclusion and wider distribution is that
Alexey wanted a cleaner interface to poll the function. Noone disagrees
and Manfred and other were proposing this some time ago of course Alexey
has the last word.
Jamal has done good converting-to-NAPI document which and this is too
dependant on the poll-call API.
NAPI code as-is today consists of:
1) ANK kernel patch. We use this in production with 2.4.16. It patches with
2.5.2 but not yet tested.
2) Tulip driver. I forked off some older kernel driver. I think Jeff has code
with his more recent kernel version. I can give Jeff a hand verifying it.
3) e1000 driver. It is not kernel tree today. Intel indicated some interest
to have this included in 2.5.X and I think thats the reason they are
now changing the BSD-ish copyright to comply better with GPL. I have at
Intel we eventfully can ask.
4) patch for 3c59x contributed. Lennert Bytenback, Andrew, Jamal, ANK
and others. There might be later revs.
5) Documentation. Jamal papers. Usenix paper and porting guide.
NAPI does not break any netif_rx drivers they run untouched with virtually
no performance degradation. Problem comes if we need to change driver API
more than once.
This is my view Jamal and Alexey will comment.
I have collected the current work:
robur.slu.se:/pub/Linux/net-development/NAPI/
Cheers.
--ro
|