From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH RFC] tcp: Allow sk_wmem_alloc to exceed sysctl_tcp_limit_output_bytes Date: Wed, 15 Apr 2015 15:19:16 +0100 Message-ID: References: <1427388414-31077-1-git-send-email-jonathan.davies@citrix.com> <1427390070.25985.145.camel@edumazet-glaptop2.roam.corp.google.com> <551555E3.80205@citrix.com> <552BC899.8090300@citrix.com> <1428933925.3834.6.camel@edumazet-glaptop2.roam.corp.google.com> <552BDAC6.2020708@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YiOA9-0006mT-Q6 for xen-devel@lists.xenproject.org; Wed, 15 Apr 2015 14:19:33 +0000 Received: by oblw8 with SMTP id w8so22174001obl.0 for ; Wed, 15 Apr 2015 07:19:31 -0700 (PDT) In-Reply-To: <552BDAC6.2020708@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Malcolm Crossley Cc: Jonathan Davies , Wei Liu , Eric Dumazet , Hideaki YOSHIFUJI , netdev , James Morris , Patrick McHardy , David Vrabel , Alexey Kuznetsov , xen-devel , Boris Ostrovsky , "David S. Miller" List-Id: xen-devel@lists.xenproject.org On Mon, Apr 13, 2015 at 4:03 PM, Malcolm Crossley wrote: >> >> 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. This sounds sensible to me, particularly if virtio_net is already doing it. -George