netdev - RE: NAPI rescheduling and the delay caused by it

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6F39C955CEA9D14BAA91CC78568B93012D5039@AMSPEX01CL02.citrite.net>
Date:	Mon, 9 Dec 2013 23:39:06 +0000
From:	Zoltan Kiss <zoltan.kiss@...rix.com>
To:	Eric Dumazet <eric.dumazet@...il.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

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

Zoli
-----Original Message-----
From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On Behalf Of Eric Dumazet
Sent: 04 December 2013 23:32
To: Zoltan Kiss
Cc: netdev@...r.kernel.org; xen-devel@...ts.xenproject.org; Malcolm Crossley; Jonathan Davies; Paul Durrant; Wei Liu; Ian Campbell
Subject: Re: NAPI rescheduling and the delay caused by it

On Wed, 2013-12-04 at 21:23 +0000, Zoltan Kiss wrote:

> I see netif_rx_ni makes sure the softirq is executed, but I'm not sure 
> I get how is it related to wake_queue. Can you explain a bit more?
> 

Calling netif_wake_queue() from process context makes no guarantee the TX softirq is processed in the following cycles.

This interface is meant to be used from softirq context.

Try to enclose it in :

void xenvif_notify_tx_completion(struct xenvif *vif) {
	if (netif_queue_stopped(vif->dev) && xenvif_rx_schedulable(vif)) {
		local_bh_disable();
		netif_wake_queue(vif->dev);
		local_bh_enable();
	}
}