[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1386638065.30495.338.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Mon, 09 Dec 2013 17:14:25 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Zoltan Kiss <zoltan.kiss@...rix.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
Malcolm Crossley <malcolm.crossley@...rix.com>,
Jonathan Davies <Jonathan.Davies@...rix.com>,
Paul Durrant <Paul.Durrant@...rix.com>,
Wei Liu <wei.liu2@...rix.com>,
Ian Campbell <Ian.Campbell@...rix.com>
Subject: RE: NAPI rescheduling and the delay caused by it
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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists