xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Zoltan Kiss <zoltan.kiss@citrix.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Cc: Jonathan Davies <Jonathan.Davies@eu.citrix.com>
Subject: netback: Delayed copy alternative
Date: Wed, 13 Nov 2013 20:29:58 +0000	[thread overview]
Message-ID: <5283E146.5000604@citrix.com> (raw)

Hi,

I'm trying to forward port delayed copy to my new grant mapping patches. 
One important problem I've faced is that classic used 
gnttab_copy_grant_page to replace the granted page with a local copy and 
unmap the grant. And this function has never been upstreamed as only 
netback used it. Unfortunately upstreaming it is not a very easy task, 
as the kernel's grant table infrastructure doesn't track at the moment 
whether the page is DMA mapped or not. It is required because we 
shouldn't proceed with the copy and replace if a device already mapped 
the page for DMA.
David came up with an alternative idea: we do this delayed copy because 
we don't want the guest's page to get stucked in Dom0 indefinitely. The 
only realistic case for that would be if the egress interface would be 
an another guest's vif, where the guest (either due to a bug or as a 
malicious attempt) doesn't empty its ring. I think it's a safe 
assumption that Dom0 otherwise doesn't hold on to packets for too long. 
Or if it does, then that's a bug we should fix instead of doing a copy 
of the packet.
If we accept that only other vif's can keep the skb indefinitely, then 
an easier solution would be to handle this problem on the RX side: the 
RX thread can also check whether this skb hanged around for too long and 
drop it. Actually, xenvif_start_xmit already checks if the guest 
provided enough slots for us to do the grant copy. If I understand it 
correctly. What do you think about such an approach?

Regards,

Zoli

             reply	other threads:[~2013-11-13 20:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-13 20:29 Zoltan Kiss [this message]
2013-11-14  9:42 ` netback: Delayed copy alternative Paul Durrant
2013-11-14 11:04   ` David Vrabel
2013-11-14 19:27   ` Timout packets in device's TX queue Zoltan Kiss
2013-11-19 16:42 ` netback: Delayed copy alternative Zoltan Kiss
2013-11-20 11:16   ` Ian Campbell
2013-11-20 12:28     ` Zoltan Kiss

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=5283E146.5000604@citrix.com \
    --to=zoltan.kiss@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Jonathan.Davies@eu.citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=malcolm.crossley@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /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).