netdev - Re: [Xen-devel] [PATCH RFC] tcp: Allow sk_wmem_alloc to exceed sysctl_tcp_limit_output

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 13 Apr 2015 16:03:34 +0100
From:	Malcolm Crossley <malcolm.crossley@...rix.com>
To:	Eric Dumazet <eric.dumazet@...il.com>,
	David Vrabel <david.vrabel@...rix.com>
CC:	Jonathan Davies <jonathan.davies@...rix.com>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	<netdev@...r.kernel.org>, James Morris <jmorris@...ei.org>,
	Patrick McHardy <kaber@...sh.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	<xen-devel@...ts.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [Xen-devel] [PATCH RFC] tcp: Allow sk_wmem_alloc to exceed sysctl_tcp_limit_output_bytes

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@...ts.xen.org
> http://lists.xen.org/xen-devel
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html