xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: ANNIE LI <annie.li@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [PATCH 0/4] Implement persistent grant in xen-netfront/netback
Date: Fri, 16 Nov 2012 19:37:00 +0800	[thread overview]
Message-ID: <50A6255C.10108@oracle.com> (raw)
In-Reply-To: <1353059821.3499.190.camel@zakaz.uk.xensource.com>



On 2012-11-16 17:57, Ian Campbell wrote:
> On Thu, 2012-11-15 at 07:03 +0000, Annie Li wrote:
>> This patch implements persistent grants for xen-netfront/netback.
> Hang on a sec. It has just occurred to me that netfront/netback in the
> current mainline kernels don't currently use grant maps at all, they use
> grant copy on both the tx and rx paths.

Ah, this patch is based on v3.4-rc3.
Current mainline kernel does not pass the netperf/netserver case. As I 
mentioned earlier, I hit BUG_ON with your debug patch too when testing 
mainline kernel with netperf/netserver.
This is interesting, I should have check the latest code.

>
> The supposed benefit of persistent grants is to avoid the TLB shootdowns
> on grant unmap, but in the current code there should be exactly zero of
> those.

Is there any performance document about current grant copy code in 
mainline kernel?

>
> If I understand correctly this patch goes from using grant copy
> operations to persistently mapping frames and then using memcpy on those
> buffers to copy in/out to local buffers. I'm finding it hard to think of
> a reason why this should perform any better, do you have a theory which
> explains it?

This patch is aiming to fix spin lock issue of grant operations, it 
comes out to avoid possible grant operations(including grant map and copy).

> (my best theory is that it has a beneficial impact on where
> the cache locality of the data, but netperf doesn't typically actually
> access the data so I'm not sure why that would matter)
>
> Also AIUI this is also doing persistent grants for both Tx and Rx
> directions?

Yes.

>
> For guest Rx does this mean it now copies twice, in dom0 from the DMA
> buffer to the guest provided buffer and then again in the guest from the
> granted buffer to a normal one?

Yes.

>
> For guest Tx how do you handle the lifecycle of the grant mapped pages
> which are being sent up into the dom0 network stack? Or are you also now
> copying twice in this case? (i.e. guest copies into a granted buffer and
> dom0 copies out into a local buffer?)

Copy twice: guest copies into a granted buffer and dom0 copies out into 
a local buffer.

>
> Did you do measurement of the Tx and Rx cases independently?

No.

> Do you know
> that they both benefit from this change (rather than for example an
> improvement in one direction masking a regression in the other).

On theory, this implementation avoid spinlock issue of grant operation, 
so they should both benefit from it.

> Were
> the numbers you previously posted in one particular direction or did you
> measure both?

One particular direction, one runs as server, the other runs as client.

Thanks
Annie
>
> Ian.
>

  reply	other threads:[~2012-11-16 11:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-15  7:03 [PATCH 0/4] Implement persistent grant in xen-netfront/netback Annie Li
2012-11-15  7:04 ` [PATCH 1/4] xen/netback: implements persistent grant with one page pool Annie Li
2012-11-15  9:10   ` Ian Campbell
2012-11-16  2:18     ` [Xen-devel] " ANNIE LI
2012-11-16  9:27       ` Ian Campbell
2012-11-16  9:55         ` ANNIE LI
2012-11-15  9:57   ` Roger Pau Monné
2012-11-16  2:49     ` ANNIE LI
2012-11-16  7:57       ` ANNIE LI
2012-11-16  9:32       ` Ian Campbell
2012-11-16 11:34         ` ANNIE LI
2012-11-15  7:04 ` [PATCH 2/4] xen/netback: Split one page pool into two(tx/rx) " Annie Li
2012-11-15  9:15   ` Ian Campbell
2012-11-16  3:10     ` ANNIE LI
2012-11-15  7:05 ` [PATCH 3/4] Xen/netfront: Implement persistent grant in netfront Annie Li
2012-11-15 10:52   ` [Xen-devel] " Roger Pau Monné
2012-11-16  5:22     ` ANNIE LI
2012-11-16  7:58       ` ANNIE LI
2012-11-15  7:05 ` [PATCH 4/4] fix code indent issue in xen-netfront Annie Li
2012-11-15  7:40 ` [PATCH 0/4] Implement persistent grant in xen-netfront/netback Pasi Kärkkäinen
2012-11-15  8:38   ` [Xen-devel] " ANNIE LI
2012-11-15  8:51     ` Ian Campbell
2012-11-15  9:02       ` ANNIE LI
2012-11-15  9:35     ` Wei Liu
2012-11-15 11:12       ` [Xen-devel] " ANNIE LI
2012-11-16 15:34       ` Konrad Rzeszutek Wilk
2012-11-15 10:56     ` Roger Pau Monné
2012-11-15 11:14       ` ANNIE LI
2012-11-15 11:15       ` Ian Campbell
2012-11-15 18:29         ` Konrad Rzeszutek Wilk
2012-11-15 19:11           ` Ian Campbell
2012-11-16 15:23             ` Konrad Rzeszutek Wilk
2012-11-16 15:21       ` Konrad Rzeszutek Wilk
2012-11-15  8:53 ` Ian Campbell
2012-11-15 11:14   ` ANNIE LI
2012-11-15  8:56 ` Ian Campbell
2012-11-15 11:14   ` [Xen-devel] " ANNIE LI
2012-11-16  9:57 ` Ian Campbell
2012-11-16 11:37   ` ANNIE LI [this message]
2012-11-16 11:46     ` Ian Campbell
2012-11-17  4:39       ` annie li
2012-11-16 15:18 ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50A6255C.10108@oracle.com \
    --to=annie.li@oracle.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=netdev@vger.kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).