Re: r8169 : always copying the rx buffer to new skb

[Eric Dumazet <eric.dumazet@gmail.com>]

Le mardi 26 avril 2011 à 22:18 -0400, John Lumby a écrit :
> Anyone have any further thoughts on the proposal to avoid memcpy'ing?  
> (see earlier post)
> 
> I also have a question concerning NAPI.     I've found that much of the 
> CPU saved from not memcpy'ing is burned in extra rx_interrupt'ing,  and 
> much of that seems to be wasted (no new packets).    So the actual 
> benefit is rather less than I think should be possible.
> 
> I've tried some tinkering with the napi weight but can't find any 
> setting which really improves the ratio of rx packets to hard interrupts 
> significantly.    The problem seems to be that each successive 
> rtl8169_poll() is driven too soon after the last one   (in this 
> particular workload).     The napi weight doesn't directly influence that.
> 
> So  -  question :
> is there any way,   when returning from rtl8169_poll,  to tell napi 
> something like :
>     "   finish this interrupt context and let something else run on this 
> CPU  (always CPU0 on my machine) BUT reschedule another napi poll on 
> this same device at some time after that "
> the point being that rtl8169_poll will,  for this case,  NOT re-enable 
> the NIC's napi interrupts,  in the hope that maybe some user work can be 
> dispatched,    so something else will have to schedule the next napi 
> poll for it.    Conceptually,    if rtl8169_poll finds no rx work done 
> on this call,   it wants to cause a yield() and then try again.     
> Except it can't from within the interrupt.
> 
> I appreciate this could lead to delays in handling new work so might be 
> dangerous,    but it seems to me to be in line with NAPI objectives so I 
> wanted to try it .   But don't know how.     Any hints or thoughts 
> appreciated.

Answer is no. There is no such facility in NAPI infrastructure.

You want to introduce a timer based polling. Some old pre-NAPI drivers
were doing that. Its OK when you have one device to handle, it can be a
nightmare when you mix several devices.