From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: Re: netback: Delayed copy alternative Date: Tue, 19 Nov 2013 16:42:52 +0000 Message-ID: <528B950C.1080500@citrix.com> References: <5283E146.5000604@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VioO9-0000Qd-6w for xen-devel@lists.xenproject.org; Tue, 19 Nov 2013 16:42:57 +0000 In-Reply-To: <5283E146.5000604@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "xen-devel@lists.xenproject.org" , Ian Campbell , Wei Liu , Paul Durrant , Malcolm Crossley , David Vrabel Cc: Jonathan Davies List-Id: xen-devel@lists.xenproject.org After further discussions and investigations, it seems it is a viable approach to drop the packets in the RX path of the another VIF after a timeout, and don't care about the rest of the cases (packets get stucked somewhere in the core stack, a driver, or in the queue of a Dom0 userspace socket. In the latter case, they get copied anyway, so it shouldn't happen) Does anyone has a counterargument? Zoli On 13/11/13 20:29, Zoltan Kiss wrote: > 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?