From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: netback: Delayed copy alternative Date: Thu, 14 Nov 2013 11:04:28 +0000 Message-ID: <5284AE3C.8070009@citrix.com> References: <5283E146.5000604@citrix.com> <9AAE0902D5BC7E449B7C8E4E778ABCD0172846@AMSPEX01CL01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vguiz-0003z0-8M for xen-devel@lists.xenproject.org; Thu, 14 Nov 2013 11:04:37 +0000 In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0172846@AMSPEX01CL01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Paul Durrant Cc: Jonathan Davies , Wei Liu , Ian Campbell , David Vrabel , Zoltan Kiss , "xen-devel@lists.xenproject.org" , Malcolm Crossley List-Id: xen-devel@lists.xenproject.org On 14/11/13 09:42, Paul Durrant wrote: > Zoltan Kiss wrote: >> >> 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? >> > > Well, now that David fixed the DMA unmap tracking thing, I believe > that another vif is *generally* the only place an skb can hang around > for a long time. The problem is that there is an edge case... If a > network driver turns off queue processing (for flow control reasons, and > NB that 10G Ethernet requires the driver to do this if the PHY signals > flow control and internal buffering is exhausted, 1G is allowed to be an > open drain) then the skb can sit in the queue indefinitely and there's > no way you can deal with this from the guest RX side of netback. You > need to have a copy-aside option to handle this. But the delayed copy won't always help in this case as the packet may be DMA mapped and queued on hardware queues. David