On 7/7/23 14:22, David Marchand wrote:
> 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.
OK. Makes sense.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
