All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Shrijeet Mukherjee <shm@cumulusnetworks.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Thomas Graf <tgraf@suug.ch>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Jakub Kicinski <kubakici@wp.pl>,
	David Miller <davem@davemloft.net>,
	alexander.duyck@gmail.com, shrijeet@gmail.com,
	tom@herbertland.com, netdev@vger.kernel.org,
	Roopa Prabhu <roopa@cumulusnetworks.com>,
	Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
	aconole@redhat.com
Subject: Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
Date: Fri, 4 Nov 2016 16:05:51 -0700	[thread overview]
Message-ID: <581D144F.8080007@gmail.com> (raw)
In-Reply-To: <20161104022927-mutt-send-email-mst@kernel.org>

On 16-11-03 05:34 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 03, 2016 at 04:29:22PM -0700, John Fastabend wrote:
>> [...]
>>
>>>>> - when XDP is attached disable all LRO using VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
>>>>>   (not used by driver so far, designed to allow dynamic LRO control with
>>>>>    ethtool)
>>>>
>>>> I see there is a UAPI bit for this but I guess we also need to add
>>>> support to vhost as well? Seems otherwise we may just drop a bunch
>>>> of packets on the floor out of handle_rx() when recvmsg returns larger
>>>> than a page size. Or did I read this wrong...
>>>
>>> It's already supported host side. However you might
>>> get some packets that were in flight when you attached.
>>>
>>
>> Really I must have missed it I don't see any *GUEST_FEATURES* flag in
>> ./drivers/vhost/?
> 
> It's all done by QEMU catching these commands and calling
> ioctls on the tun/macvtap/packet socket.
> 

Well at least for the tap vhost backend in linux that I found here,

 ./qemu/net/tap-linux.c

there is no LRO feature flag but that is OK I can get it working next
week looks fairly straight forward.

[...]

>> And if I try to merge the last email I sent out here. In mergeable and
>> big_packets modes if LRO is off and MTU < PAGE_SIZE it seems we should
>> always get physically contiguous data on a single page correct?
> 
> Unfortunately not in the mergeable buffer case according to spec, even though
> linux hosts will do that, so it's fine to optimize for that
> but need to somehow work in other cases e.g. by doing a data copy.
> 

ah OK this makes sense I was looking at vhost implementation in Linux.

> 
>> It
>> may be at some offset in a page however. But the offset should not
>> matter to XDP. If I read this right we wouldn't need to add a new
>> XDP mode and could just use the existing merge or big modes. This would
>> seem cleaner to me than adding a new mode and requiring a qemu option.
>>
>> Thanks for all the pointers by the way its very helpful.
> 
> So for mergeable we spend cycles trying to make buffers as small
> as possible and I have a patch to avoid copies for that too,
> I'll post it next week hopefully.
> 

Good to know. I'll get the XDP stuff wrapped up next week or see
if Srijeet wants to do it.

Thanks,
John

  reply	other threads:[~2016-11-04 23:06 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-22  4:07 [PATCH net-next RFC WIP] Patch for XDP support for virtio_net Shrijeet Mukherjee
2016-10-23 16:38 ` Stephen Hemminger
2016-10-24  1:51   ` Shrijeet Mukherjee
2016-10-25  1:10     ` Alexei Starovoitov
2016-10-25 17:36 ` Jakub Kicinski
2016-10-26 13:52 ` Jesper Dangaard Brouer
2016-10-26 16:36   ` Michael S. Tsirkin
2016-10-26 16:52     ` David Miller
2016-10-26 17:07       ` Michael S. Tsirkin
2016-10-26 17:11         ` David Miller
2016-10-27  8:55           ` Jesper Dangaard Brouer
2016-10-27 21:09             ` John Fastabend
2016-10-27 21:30               ` Michael S. Tsirkin
2016-10-27 21:42                 ` David Miller
2016-10-27 22:25                   ` Michael S. Tsirkin
2016-10-28  1:35                     ` David Miller
2016-10-28  1:43                       ` Alexander Duyck
2016-10-28  2:10                         ` David Miller
2016-10-28 15:56                           ` John Fastabend
2016-10-28 16:18                             ` Jakub Kicinski
2016-10-28 18:22                               ` Alexei Starovoitov
2016-10-28 20:35                                 ` Alexander Duyck
2016-10-28 20:42                                   ` Jakub Kicinski
2016-10-28 20:36                                 ` Jakub Kicinski
2016-10-29  3:51                                 ` Shrijeet Mukherjee
2016-10-29 11:25                                   ` Thomas Graf
2016-11-02 14:27                                     ` Jesper Dangaard Brouer
2016-11-03  1:28                                       ` Shrijeet Mukherjee
2016-11-03  4:11                                         ` Michael S. Tsirkin
2016-11-03  6:44                                           ` John Fastabend
2016-11-03 22:20                                             ` John Fastabend
2016-11-03 22:42                                             ` Michael S. Tsirkin
2016-11-03 23:29                                               ` John Fastabend
2016-11-04  0:34                                                 ` Michael S. Tsirkin
2016-11-04 23:05                                                   ` John Fastabend [this message]
2016-11-06  6:50                                                     ` Michael S. Tsirkin
2016-10-28 17:11                             ` David Miller
2016-10-30 22:53                               ` Michael S. Tsirkin
2016-11-02 14:01                               ` Jesper Dangaard Brouer
2016-11-02 16:06                                 ` Alexander Duyck
2016-10-28  0:02               ` Shrijeet Mukherjee
2016-10-28  0:46                 ` Shrijeet Mukherjee

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=581D144F.8080007@gmail.com \
    --to=john.fastabend@gmail.com \
    --cc=aconole@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=kubakici@wp.pl \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@cumulusnetworks.com \
    --cc=roopa@cumulusnetworks.com \
    --cc=shm@cumulusnetworks.com \
    --cc=shrijeet@gmail.com \
    --cc=tgraf@suug.ch \
    --cc=tom@herbertland.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.