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: <9AAE0902D5BC7E449B7C8E4E778ABCD01ABD49@AMSPEX01CL01.citrite.net>
Date:	Tue, 10 Dec 2013 10:52:58 +0000
From:	Paul Durrant <Paul.Durrant@...rix.com>
To:	Ian Campbell <Ian.Campbell@...rix.com>
CC:	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Wei Liu <wei.liu2@...rix.com>,
	David Vrabel <david.vrabel@...rix.com>
Subject: RE: [PATCH net] xen-netback: fix abuse of napi budget

> -----Original Message-----
> From: Ian Campbell
> Sent: 10 December 2013 10:26
> To: Paul Durrant
> Cc: xen-devel@...ts.xen.org; netdev@...r.kernel.org; Wei Liu; David Vrabel
> Subject: Re: [PATCH net] xen-netback: fix abuse of napi budget
> 
> On Tue, 2013-12-10 at 10:16 +0000, Paul Durrant wrote:
> > netback seemed to be somewhat confused about the napi budget
> parameter and
> > basically ignored it. This patch fixes that, properly limiting the work done
> > in each poll.
> 
> What do you mean "ignored", xenvif_tx_submit seems to be tracking and
> testing work_done against the budget.
> 
> I suspect this change is probably worthwhile but it would be good to get
> an accurate description of why, which I presume is because the tx
> process is xenvif_tx_build_gops followed by, gnttab_batch_copy then
> xenvif_tx_submit and that it is better to do the budget enforcement
> earlier on.
> 

Yes, the budget needs to limit what we process from the shared ring because otherwise we risk tx_queue growing without bound.

> How does this change impact the batching in gnttab_batch_copy and
> therefore performance? Do we need to tweak the the NAPI budget to
> ensure
> we are getting good batching? I suspect that netback is a bit unusual
> among NIC drivers in that the rx path contains a fair bit of actual work
> to do, so perhaps the NAPI defaults are not necessarily going to be the
> best for it.
> 

We have a budget of 64 at the moment, which I think is big enough and actually possibly too big. We need a value that gives us a reasonable amount of grant op batching but isn't so big that we're forever bouncing and in and out of interrupt mode, which I suspect is what's happening now. It would be really useful if napi budget could be tuned dynamically so we could run some perf tests without having to reload but google has drawn a blank so far.

  Paul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ