[Click] [RFC] [PATCH] PollDevice/ToDevice improvement

[springbo@cs.wisc.edu]

Hi Joonwoo,

Outstanding idea! Thanks for sharing your hard work.

I attempted to use the patch on a Core2 machine with an Intel® PRO/1000 PT
Dual Port Server Adapter (82571GB). The patch did not work with my
controller. Shortly after starting click the machine hung with an invalid
opcode Oops (no trace). I assume due to controller differences.

NAPI drivers would be a big benefit for us. So much so that as soon as I
find time I'm going to try to do something similar for the 82571GB
controller. It would be very helpful if you could get me started by
pointing me to a few sections of the code where you think these
unsupported operations might be.


I'm not sure what your plans are for these patches, but a couple of minor
nitpicks:
-Line 4081 [adapter->poll_intr(netdev, (void*)flags);] in e1000_main.c
gave a warning on a x86_64 machine.
-The value of netdev->polling now has meaning beyond simply being <0, 0,
>0. It might be helpful if you used constants for the positive values
(maybe POLLING_INTERRUPTS, POLLING_NO_INTERRUPTS)
-Along the same lines you might update the documentation about the meaning
of net_device->polling in netdevice.h.


Thanks!
Kevin Springborn






> I think polling packet method of the click which is implemented with
> polldevice and todevice is one of great advantage of it.
> But IMO it has some disadvantage too because click does old fashioned
> polling packets which is spinning infinitely.
> Therefore I think that the spinning eats much of processor time and makes
> influence to other tasks.
> Then I managed to interrupt driven polling packet method for click which
> is using NAPI.
> It makes limited number of interrupts in a sec and notifications to
> polldevice and todevice.
> Especially It makes polldevice to use rx descriptors of nic (e1000) too.
> Actually because old polldevice does spinning infinitely, it does not give
> chance to nic for queuing.
>
> In simple elements test (to maximizing performance for spinning method),
> my patch had slightly increased or almost same performance
> comparing to spinning method and processor usage was greatly decreased.
> (about 1050000pps receive and 45% processor usage on Intel
> core2 1.86 with e1000 82573L gigabit nic)
>
> * I don't have precise network benchmark system like a smartbit, so I'll
> be so much pleased someone measures the performance of this
> patch.
> * All test was performed on e1000 52547L, I'm afraid it won't work on the
> other e1000 nic.
> * Please apply patch for linux after click it selves. (2.6.19.2)
> * Patch contains e1000 link detection fix too
> (partially
> https://pdos.csail.mit.edu/pipermail/click/2007-October/006447.html)
> * It does not contain ToDevice multi-threading fix
> (https://pdos.csail.mit.edu/pipermail/click/2007-October/006436.html)
>
> Eddie, Can you check this please?
>
> Thanks in advance.
>
> joonwpark.tistory.com
> Joonwoo
>