On Fri, Jul 7, 2023 at 1:50 PM Ilya Maximets <i.maxim...@ovn.org> wrote:
> > @@ -4268,7 +4295,9 @@ new_device(int vid)
> > dev->hw_ol_features |= NETDEV_TX_SCTP_CKSUM_OFFLOAD;
> > }
> >
> > - if (userspace_tso_enabled()) {
> > + if (userspace_tso_enabled()
> > + && dev->virtio_features_state & OVS_VIRTIO_F_CLEAN) {
>
> If this needed? There is no harm in using these features on Tx if negotiated.
I did not test without it.
Without this limitation, this means that the host/OVS can make tso
offloading requests to the guest, but the guest can't make them to the
host.
Iow, on the host side, TSO would be advertised to OVS layers, and
would be displayed in the port status field.
On the guest side, TSO would be forbidden.
I find this asymmetry confusing.
If you don't have access to the guest (which happens in deployments
with VNF as black boxes), the only chance to catch that the workaround
is in effect is to look at the "userspace-tso" field that gets added
by this patch.
But to know about this field, you would have to get a hint something
is wrong on the TSO side.
With announcing that TSO is off for both sides of this vhost port, I
think we have more chances a user would search in OVS documentation
and find out about the "userspace-tso" status field.
--
David Marchand
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
