On Wed, Jul 5, 2023 at 7:02 PM Maxime Coquelin
<maxime.coque...@redhat.com> wrote:
>
> On 7/5/23 15:36, David Marchand wrote:
> > On Wed, Jul 5, 2023 at 3:22 PM Maxime Coquelin
> > <maxime.coque...@redhat.com> wrote:
> >> @@ -950,9 +954,14 @@ rte_vhost_driver_register(const char *path, uint64_t
> >> flags)
> >> * two values.
> >> */
> >> vsocket->use_builtin_virtio_net = true;
> >> - vsocket->supported_features = VIRTIO_NET_SUPPORTED_FEATURES;
> >> - vsocket->features = VIRTIO_NET_SUPPORTED_FEATURES;
> >> - vsocket->protocol_features = VHOST_USER_PROTOCOL_FEATURES;
> >> + if (vsocket->is_vduse) {
> >> + vsocket->supported_features = VDUSE_NET_SUPPORTED_FEATURES;
> >> + vsocket->features = VDUSE_NET_SUPPORTED_FEATURES;
> >> + } else {
> >> + vsocket->supported_features =
> >> VIRTIO_NET_SUPPORTED_FEATURES;
> >> + vsocket->features =
> >> VIRTIO_NET_SUPPORTED_FEATURES;
> >> + vsocket->protocol_features = VHOST_USER_PROTOCOL_FEATURES;
> >> + }
> >>
> >
> > Would it make sense to split those features in a set of features
> > shared by vhost-user and vduse, and one dedicated set for each of
> > them?
> > For example, the VIRTIO_NET_F_GUEST/HOST_* features are not bound to
> > vhost-user / vduse, are they?
>
> Most of the features are the same, but there are a few differences:
> - VIRTIO_F_RING_PACKED: this is not really Vhost or VDUSE specific. The
> issue is we just lack packed ring support in the control queue
> implementation, only used by VDUSE for now. I expect to add it in
> v23.11.
>
> - VHOST_USER_F_PROTOCOL_FEATURES: This feature is Vhost-user specific
>
> - VHOST_F_LOG_ALL: This is for live-migration, maybe it will be
> advertised by VDUSE in the future, but we miss live-migration support in
> Kernel VDUSE at the moment.
>
> - VIRTIO_NET_F_CTRL_RX: This is advertised by Vhost-user, but it does
> not do anything specific. While if we do it in VDUSE, we need to
> implement its support in CVQ.
>
> To summarize, we have some features specific to Vhost-user, but for the
> other differences, this is just some features are not yet
> implemented/tested with VDUSE.
>
> Maybe we could have something like this, which has the advantage to
> highlight the gaps we have in VDUSE (not compiled/tested):
LGTM on the principle.
Thanks Maxime.
--
David Marchand
