From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Malcolm Crossley <malcolm.crossley@citrix.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
David Vrabel <david.vrabel@citrix.com>,
Jonathan Davies <jonathan.davies@citrix.com>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
netdev <netdev@vger.kernel.org>, James Morris <jmorris@namei.org>,
"David S. Miller" <davem@davemloft.net>,
xen-devel <xen-devel@lists.xenproject.org>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Patrick McHardy <kaber@trash.net>, Wei Liu <Wei.Liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC] tcp: Allow sk_wmem_alloc to exceed sysctl_tcp_limit_output_bytes
Date: Wed, 15 Apr 2015 15:19:16 +0100 [thread overview]
Message-ID: <CAFLBxZaDPa0Em6z-bwg1HoLqCU9R_rWD8ri+0sNVgX-Httj_1A@mail.gmail.com> (raw)
In-Reply-To: <552BDAC6.2020708@citrix.com>
On Mon, Apr 13, 2015 at 4:03 PM, Malcolm Crossley
<malcolm.crossley@citrix.com> 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
next prev parent reply other threads:[~2015-04-15 14:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 16:46 [PATCH RFC] tcp: Allow sk_wmem_alloc to exceed sysctl_tcp_limit_output_bytes Jonathan Davies
2015-03-26 17:14 ` Eric Dumazet
2015-03-27 13:06 ` Jonathan Davies
2015-04-13 13:46 ` [Xen-devel] " David Vrabel
2015-04-13 14:05 ` Eric Dumazet
2015-04-13 15:03 ` Malcolm Crossley
2015-04-15 14:19 ` George Dunlap [this message]
2015-04-15 14:36 ` Ian Campbell
2015-04-15 16:42 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFLBxZaDPa0Em6z-bwg1HoLqCU9R_rWD8ri+0sNVgX-Httj_1A@mail.gmail.com \
--to=george.dunlap@eu.citrix.com \
--cc=Wei.Liu2@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=davem@davemloft.net \
--cc=david.vrabel@citrix.com \
--cc=eric.dumazet@gmail.com \
--cc=jmorris@namei.org \
--cc=jonathan.davies@citrix.com \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=malcolm.crossley@citrix.com \
--cc=netdev@vger.kernel.org \
--cc=xen-devel@lists.xenproject.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).