On 13/04/15 15:05, Eric Dumazet wrote: > On Mon, 2015-04-13 at 14:46 +0100, David Vrabel wrote: > >>> And the proof-of-concept patch for idea (b) I used was: >>> >>> @@ -552,6 +552,8 @@ static int xennet_start_xmit(struct sk_buff *skb, >>> struct net_device *dev) >>> goto drop; >>> } >>> >>> + skb_orphan(skb); >>> + >>> page = virt_to_page(skb->data); >>> offset = offset_in_page(skb->data); >>> len = skb_headlen(skb); >> >> No. This a bunch of allocations and a full memcpy of all the frags. > > skb_orphan() does nothing like that.
I think David accidently read the skb_orphan_frags() code. > > But the main concern here is it basically breaks back pressure. > > And you do not want this, unless there is no other choice. > virtio_net already use's skb_orphan() in it's transmit path. It seems only fair that other virtual network drivers behave in the same way. There are no easy solutions to decrease the transmit latency for netback/netfront. We map the guest memory through to the backend to avoid memory copies. The frontend memory can only be freed once the network driver has completed transmitting the packet in the backend. Modern network drivers can be quite slow at freeing the skb's once transmitted (the packet is already on the wire as far as they are concerned) and this delay is compounded by needing the signal the completion of the transmit back to the frontend (by IPI in worst case). >From a networking point of view, the backend is a switch. Is it OK to consider the packet to have been transmitted from the guest point of view once the backend is aware of the packet? This would help justify the skb_orphan() in the frontend. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
