Re: [Xen-devel] NAPI rescheduling and the delay caused by it

[Eric Dumazet <eric.dumazet@xxxxxxxxx>]

On Mon, 2013-12-09 at 23:39 +0000, Zoltan Kiss wrote:
> Hi,
> 
> I tried that, it didn't help in my case. I think
> xenvif_notify_tx_completion is only a shortcut to wake the queue
> earlier. Otherwise we should wait for the interrupt from the guest to
> arrive (see rx_interrupt), however we know it can be done. Or does
> this call from the kernel thread makes things worse than a later call
> from the interrupt context?

Well, the call through ksoftirqd only adds some latency, and extra
context switch. This is delayed by the time your current process exits
the kernel (or you need CONFIG_PREEMPT)

> I found another suspect however: my grant mapping patches do the
> unmapping from the NAPI instance where otherwise we receive the
> packets from the guest. But this means we call napi_schedule from the
> zerocopy callback, which can be run by anyone who free up that skb,
> including an another VIF's RX thread (which actually does the transmit
> TO the guest). I guess that might be bad.

Same problem : napi_schedule() is meant to be used from interrupt
context.





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel