On Wed, May 12, 2021 at 4:33 AM Jason Wang <jasowang@xxxxxxxxxx> wrote: > > > 在 2021/5/11 下午4:33, Yuri Benditovich 写道: > > On Tue, May 11, 2021 at 9:50 AM Jason Wang <jasowang@xxxxxxxxxx> wrote: > >> > >> 在 2021/5/11 下午12:42, Yuri Benditovich 写道: > >>> Signed-off-by: Yuri Benditovich <yuri.benditovich@xxxxxxxxxx> > >>> --- > >>> 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 this > > No 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. > > Thanks > > > > > >> 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. > > > >> Thanks > >> > >> > >>> } > >>> > >>> /* This gives the user a way to test for new features in future by > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
