[Click] Click and e1000e

[Adam Greenhalgh]

2008/8/27 Eddie Kohler <kohler at cs.ucla.edu>:
> 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
>
Thank you for the clarification. I think I agree with you that one
element per device queue is the right model but like you I'm tempted
by the single element per card approach too. The single element per
device or "filtered" queue lends its self very well to the case where
you have a combination of a filter queue (vmdq) using RSS to spread
the traffic out to sub queues.

If you want to complicate matters further there is a question whether
you want to try and support splitting the ownership of the nic between
many virtual guest domains and how that might be done ... its all
rather scary at this point .

Adam