[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?


On 13/11/13 20:29, 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?

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.