[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <581D144F.8080007@gmail.com>
Date: Fri, 4 Nov 2016 16:05:51 -0700
From: John Fastabend <john.fastabend@...il.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Shrijeet Mukherjee <shm@...ulusnetworks.com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Thomas Graf <tgraf@...g.ch>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Jakub Kicinski <kubakici@...pl>,
David Miller <davem@...emloft.net>, alexander.duyck@...il.com,
shrijeet@...il.com, tom@...bertland.com, netdev@...r.kernel.org,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
aconole@...hat.com
Subject: Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
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
Powered by blists - more mailing lists