Re: [libvirt] [dpdk-dev] dpdk/vpp and cross-version migration for vhost
On 11/28/2016 11:18 PM, Thomas Monjalon wrote:
2016-11-28 16:28, Maxime Coquelin:
> On 11/24/2016 04:24 PM, Kavanagh, Mark B wrote:
>> DPDK v16.04 added support for vHost User TSO; as such, by default,
>> TSO is advertised to guest devices as an available feature during
>> feature negotiation with QEMU.
>> However, while the vHost user backend sets up the majority of the
>> mbuf fields that are required for TSO, there is still a reliance
>> on the associated DPDK application (i.e. in this case OvS-DPDK)
>> to set the remaining flags and/or offsets.
>> Since OvS-DPDK doesn't currently provide that functionality, it is
>> necessary to explicitly disable TSO; otherwise, undefined behaviour
>> will ensue.
>
> Thanks Mark for the clarification.
>
> In this case, maybe we could add a DPDK build option to disable Vhost's
> TSO support, that would be selected for OVS packages?
Why do you prefer a build-time option rather than the run-time config
with rte_vhost_feature_disable()? Because we need to lock the features?
Right, we need to know what the backend supports before it is started,
so that management tool can check where it could be migrated to.
Reminder: build-time configuration options are forbidden in DPDK for
such usage. It would prevent other applications from using the feature
in a given distribution, just because it is not implemented in OVS.
I understand, this is not the right solution.
I proposed this because I misunderstood how the distributions package
OVS+DPDK.
> Does that sound reasonable?
Maybe I'm missing something but I feel it is more reasonnable to implement
the missing code in OVS.
Yes, that would be the ideal solution.
OVS implements TSO and we let management tool decide whether or not
enabling the features.
While this is done, we could deprecate rte_vhost_feature_disable, and
print error message notifying the user it should be done my the
management tool.
If something is missing in DPDK, do not hesitate to request or add
more
helper functions.
Sure.
Thanks,
Maxime