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

[David Vrabel <david.vrabel@xxxxxxxxxx>]

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

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