[Click] Click and e1000e

[Roman Chertov]

Joonwoo Park wrote:
> Hi guys,
> 
>> 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.

Yes, I agree that a task per hardware queue on a 10GE will be 
beneficial.  However, I don't think it can work for a CBR UDP flow as 
there is nothing to distinguish the packets to allow the device driver 
to receive into multiple queues.  The device relies on RSS hashes to 
distinguish packets.  Further, there still might be an issue with trying 
to aggregate all of the packets from separate queues into the original 
serial order.

> 
>>> 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.

I think the new PollDevice should support NAPI style mode; however, it 
should also preserve the old mode, as it is very good for cases when you 
want to minimize variance of when the packets are received from the wire.

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

In a way that occurs through bursts.  PollDevice will sit in a loop 
until it gets nothing or BURST packets, then it sends them upstream.

Roman

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