[Click] Click and e1000e

[Joonwoo Park]

Hi guys,

2008/8/26 Roman Chertov <rchertov at cs.ucsb.edu>:
>>
>> 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
>
> The polling device is attached to a thread and then it generates tasks.
>  While executing a task, passive elements are executed until a queue is
> encountered or the packet is dropped.  Note, the elements that are the
> task chain will execute on the CPU on which the task is scheduled.  So I
> don't think that having multiple polling outputs is in violation of the
> threading model.  Please correct me if I am wrong.

However one polldevice forks only one task, so polldevice can utilize
only one processor for now.
But if polldevice (and other tasks) can fork more than one tasks, it
could be big benefit to utilize processors.
I think Adam wants 'task per hardware queue'.  It will be good for performance.

>
>> 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 .
>
> I think for a 10GE card this might be a good approach (provided the
> PCI-E bus does not become a bottleneck).  However, for e1000e and igb
> drivers I think it will result in too many wasted cycles.

I agree with you as you discussed with instance messenger :-), we are
loosing too many cycles for polling.
IMHO, I think it's time to re-enable interrupt for click polling.
Since we disabled interrupt, we should poll & rx clean & tx clean infinitely.
I want to push my last NAPI like polling patch to Eddie again.

And I think if click has push & pull multiple skb (skb list), it could
be good for performance.

Thanks,
Joonwoo

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