On Tue, May 11, 2021 at 9:50 AM Jason Wang <jasowang at redhat.com> wrote:> > > ? 2021/5/11 ??12:42, Yuri Benditovich ??: > > Signed-off-by: Yuri Benditovich <yuri.benditovich at daynix.com> > > --- > > 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.> > 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 >
On Tue, May 11, 2021 at 11:33 AM Yuri Benditovich <yuri.benditovich at daynix.com> wrote:> > On Tue, May 11, 2021 at 9:50 AM Jason Wang <jasowang at redhat.com> wrote: > > > > > > ? 2021/5/11 ??12:42, Yuri Benditovich ??: > > > Signed-off-by: Yuri Benditovich <yuri.benditovich at daynix.com> > > > --- > > > 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. > > > > > 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. >I'll add this feature to the tap.c also (AFAIU this will enable the USO for macvtap). Please correct me if I'm mistaken.> > > > Thanks > > > > > > > } > > > > > > /* This gives the user a way to test for new features in future by > >
? 2021/5/11 ??4:33, Yuri Benditovich ??:> On Tue, May 11, 2021 at 9:50 AM Jason Wang <jasowang at redhat.com> wrote: >> >> ? 2021/5/11 ??12:42, Yuri Benditovich ??: >>> Signed-off-by: Yuri Benditovich <yuri.benditovich at daynix.com> >>> --- >>> 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). 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