> -----Original Message----- > From: Hao Chen <ch...@yusur.tech> > Sent: Tuesday, October 11, 2022 10:55 AM > To: maxime.coque...@redhat.com; Xia, Chenbo <chenbo....@intel.com> > Cc: dev@dpdk.org; ho...@yusur.tech; z...@yusur.tech > Subject: [PATCH v2] vhost: enable CONFIG feature for vdpa > > Enable this feature, so that libvirt or qemu can call vdpa vendor > driver's ops '.get_config' through 'vhost_net_get_config' to get > the mac address of the vdpa hardware without manual configuration. > > v1->v2: > Move VHOST_USER_PROTOCOL_F_CONFIG from VHOST_USER_PROTOCOL_FEATURES > to function 'rte_vhost_driver_get_protocol_features'.
Don't add above version info to commit log. Refer to below link about where to add the info. http://patchwork.dpdk.org/project/dpdk/patch/20221102111713.507-1-ano...@marvell.com/ > > Signed-off-by: Hao Chen <ch...@yusur.tech> > --- > lib/vhost/socket.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/lib/vhost/socket.c b/lib/vhost/socket.c > index a8df2d484a..df8f26a5bd 100644 > --- a/lib/vhost/socket.c > +++ b/lib/vhost/socket.c > @@ -808,6 +808,10 @@ rte_vhost_driver_get_protocol_features(const char > *path, > *protocol_features = vsocket->protocol_features > & vdpa_protocol_features; > > + /* Get the unique features of vdpa */ > + if (vdpa_protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_CONFIG)) > + *protocol_features |= (1ULL << VHOST_USER_PROTOCOL_F_CONFIG); > + This makes think about what should 'vsocket->protocol_features' mean. If we do like above, for every new protocol feature that some vdpa device can support but built-in vhost-net can't support, such logic is needed. Maybe we should define something like base protocol features that vhost lib supports and some features for backend-specific. So for vdpa case, just do 'base_feature | vdpa_protocol_features'. In current VHOST_USER_PROTOCOL_FEATURES, some are general feature that vhost lib supports, but some seems not (like VHOST_USER_PROTOCOL_F_CRYPTO_SESSION). @Maxime, what do you think? Thanks, Chenbo > unlock_exit: > pthread_mutex_unlock(&vhost_user.mutex); > return ret; > -- > 2.34.1
