[Click] Click and e1000e

[Adam Greenhalgh]

2008/8/25 Roman Chertov <rchertov at cs.ucsb.edu>:
> Adam Greenhalgh wrote:
>>
>> Hi,
>>
>> I've been playing with the ixgbe driver, I have reception for a single
>> queue working but am currently trying to get multiqueue support
>> working.
>>
>> Does any one have any thoughts on how click should handle NICs which
>> support multi queuing ? Our current thinking is that each queue needs
>> a separate click "poll" element to enable multithreading to work.
>> However this breaks the current poll element device ownership model.
>
> I am not sure if creating a poll element per queue is good idea, as it will
> generate a lot of wasted cycles.  I think it would be better to configure a
> PollDevice to have multiple outputs corresponding to the number of queues it
> is configured to serve.  Also, I am not sure how many people will want to
> use the Microsoft toeplitz RSS hash to enable multiple input queuing in the
> first place.
>
> ToDevice in polling mode can be made to accept multiple input ports and then
> according to the port it would put the packet in the corresponding output
> queue.  Then the card will serve the output queues in round robin fashion.
>  I think it might be interesting to modify ToDevice further, to allow
> priority processing of the output queues.
>

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 .

Adam