From: Jason Wang <jasowang@redhat•com>
To: "Michael S. Tsirkin" <mst@redhat•com>
Cc: Willem de Bruijn <willemb@google•com>,
Network Development <netdev@vger•kernel.org>,
David Miller <davem@davemloft•net>,
Eric Dumazet <eric.dumazet@gmail•com>,
Daniel Borkmann <dborkman@redhat•com>
Subject: Re: [PATCH rfc] packet: zerocopy packet_snd
Date: Thu, 27 Nov 2014 09:18:12 +0008 [thread overview]
Message-ID: <1417079412.18179.3@smtp.corp.redhat.com> (raw)
In-Reply-To: <20141126211748.GA11904@redhat.com>
On Thu, Nov 27, 2014 at 5:17 AM, Michael S. Tsirkin <mst@redhat•com>
wrote:
> On Wed, Nov 26, 2014 at 02:59:34PM -0500, Willem de Bruijn wrote:
>> > The main problem with zero copy ATM is with queueing disciplines
>> > which might keep the socket around essentially forever.
>> > The case was described here:
>> > https://lkml.org/lkml/2014/1/17/105
>> > and of course this will make it more serious now that
>> > more applications will be able to do this, so
>> > chances that an administrator enables this
>> > are higher.
>>
>> The denial of service issue raised there, that a single queue can
>> block an entire virtio-net device, is less problematic in the case
>> of
>> packet sockets. A socket can run out of sk_wmem_alloc, but a prudent
>> application can increase the limit or use separate sockets for
>> separate flows.
>
> Socket per flow? Maybe just use TCP then? increasing the limit
> sounds like a wrong solution, it hurts security.
>
>> > One possible solution is some kind of timer orphaning frags
>> > for skbs that have been around for too long.
>>
>> Perhaps this can be approximated without an explicit timer by
>> calling
>> skb_copy_ubufs on enqueue whenever qlen exceeds a threshold value?
>
> Hard to say. Will have to see that patch to judge how robust this is.
This could not work, consider if the threshold is greater than vring
size
or vhost_net pending limit, transmission may still be blocked.
next prev parent reply other threads:[~2014-11-27 9:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 20:44 [PATCH rfc] packet: zerocopy packet_snd Willem de Bruijn
2014-11-26 18:24 ` Michael S. Tsirkin
2014-11-26 19:59 ` Willem de Bruijn
2014-11-26 21:17 ` Michael S. Tsirkin
2014-11-27 9:10 ` Jason Wang [this message]
2014-11-27 10:44 ` Michael S. Tsirkin
2014-11-28 0:39 ` Willem de Bruijn
2014-11-28 6:21 ` Jason Wang
2014-11-26 21:20 ` Michael S. Tsirkin
2014-11-26 23:05 ` Willem de Bruijn
2014-11-27 7:27 ` Michael S. Tsirkin
2014-11-28 0:32 ` Willem de Bruijn
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=1417079412.18179.3@smtp.corp.redhat.com \
--to=jasowang@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dborkman@redhat$(echo .)com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=mst@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=willemb@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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