Re: [PATCH 4/4] tun: indicate support for USO feature
From: Yuri Benditovich <hidden>
Date: 2021-05-12 05:24:49
Also in:
lkml, netdev
On Wed, May 12, 2021 at 4:33 AM Jason Wang [off-list ref] wrote:
在 2021/5/11 下午4:33, Yuri Benditovich 写道:quoted
On Tue, May 11, 2021 at 9:50 AM Jason Wang [off-list ref] wrote:quoted
在 2021/5/11 下午12:42, Yuri Benditovich 写道:quoted
Signed-off-by: Yuri Benditovich <redacted> --- drivers/net/tun.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 84f832806313..a35054f9d941 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c@@ -2812,7 +2812,7 @@ static int set_offload(struct tun_struct *tun, unsigned long arg) arg &= ~(TUN_F_TSO4|TUN_F_TSO6); } - arg &= ~TUN_F_UFO; + arg &= ~(TUN_F_UFO|TUN_F_USO);It looks to me kernel doesn't use "USO", so TUN_F_UDP_GSO_L4 is a better name for thisNo problem, I can change it in v2 and I guess we should toggle NETIF_F_UDP_GSO_l4 here? No, we do not, because this indicates only the fact that the guest can send large UDP packets and have them splitted to UDP segments.Actually the reverse. The set_offload() controls the tuntap TX path (guest RX path).
The set_offloads does 2 things: 1. At the initialization time qemu probes set_offload(something) to check which features are supported by TAP/TUN. 2. Later it configures the guest RX path according to guest's needs/capabilities Typical initialization sequence is (in case the QEMU supports USO feature): TAP/TUN set offload 11 (probe for UFO support) TAP/TUN set offload 21 (probe for USO support) TAP/TUN set offload 0 ... TAP/TUN set offload 7 (configuration of offloads according to GUEST features) This series of patches is for VIRTIO_NET_F_HOST_USO only, virtio-net features like VIRTIO_NET_F_GUEST_USO_(4/6/whatever) are not defined in the spec yet.
When VIRTIO_NET_F_GUEST_XXX was not negotiated, the corresponding netdev features needs to be disabled. When host tries to send those packets to guest, it needs to do software segmentation. See virtio_net_apply_guest_offloads(). There's currently no way (or not need) to prevent tuntap from receiving GSO packets. Thanksquoted
quoted
And how about macvtap?We will check how to do that for macvtap. We will send a separate patch for macvtap or ask for advice.quoted
Thanksquoted
} /* This gives the user a way to test for new features in future by
_______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization