2008/8/25 Roman Chertov <[EMAIL PROTECTED]>: > 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 _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
