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
