Re: [Xen-devel] netback: Delayed copy alternative

[Zoltan Kiss <zoltan.kiss@xxxxxxxxxx>]

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?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel