Re: low latency/busy poll feedback and bugs

[Eliezer Tamir <eliezer.tamir@linux.intel.com>]

On 06/08/2013 21:08, Shawn Bohrer wrote:
> On Tue, Aug 06, 2013 at 10:41:48AM +0300, Eliezer Tamir wrote:
>> For multicast, it is possible that incoming packets to come from more
>> than one port (and therefore more than one queue).
>> I'm not sure how we could handle that, but what we have today won't do
>> well for that use-case.
>  
> It is unclear to me exactly what happens in this case.  With my simple
> patch I'm assuming it will spin on the receive queue that received the
> last packet for that socket.  What happens when a packet arrives on a
> different receive queue than the one we were spinning on? I assume it
> is still delivered but perhaps the spinning process won't get it until
> the spinning time expires?  I'm just guessing and haven't attempted to
> figure it out from looking through the code.

What will happen is that the current code will only busy poll on one
queue, sometimes on this one, sometimes on that one.

packets arriving on the other queue will still be serviced but will
suffer the latency of waiting for NAPI to schedule.

So your avg will be better, but your std. dev. much worse and it's
probably not worth it if you really expect two devices to receive
data at the same time.