[Click] Click and e1000e

[Eddie Kohler]

Adam Greenhalgh wrote:
> Unless I've miss understood click's threading model, a single poll
> device element with multiple outputs can only be assigned to one
> thread and hence once cpu. To be able to poll a 10G interface at line
> rate you need to assign between 3 and 4 cpus to the device, hence the
> need for multiple elements. A single core of a 2.6Ghz Xeon can only
> poll about 2.8 Mp/s .

* This does misunderstand Click's threading model.  Elements are not assigned 
to RouterThreads, Task objects are; and although no current element has 
multiple Tasks, there's no inherent reason why not.  PollDevice could have N 
Task objects, one per device queue.

* Nevertheless, I think one-element-per-queue might fit the Click style a 
little better.  And it wouldn't be that hard to implement, I think.

* One reason to use a single element for the device might be if switching a 
device to polling mode by necessity claims all of its queues (stops Linux from 
processing any of the device's queues).  In that case, might it be easier to 
understand if the device element claims all queues?

Overall I'd say I leaned towards one element per device queue, with something 
like a SUBDEVICE keyword argument that took a list of queues to poll.
Eddie


> 
> Adam
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click