[dpdk-dev] [PATCH] net/virtio-user: add unsupported features mask

[dpdk-dev] [PATCH] net/virtio-user: add unsupported features mask

[Marvin Liu]

This patch introduces unsupported features mask for virtio-user device.
For virtio-user server mode, when reconnecting virtio-user will
retrieve vhost devcie features as base and then unmask unsupported
features.

Signed-off-by: Marvin Liu <yong.liu@intel.com>

diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index 4322527f2..360a92eae 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -384,6 +384,7 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
 	dev->queue_pairs = 1; /* mq disabled by default */
 	dev->queue_size = queue_size;
 	dev->mac_specified = 0;
+	dev->unmask_features = 0;
 	parse_mac(dev, mac);
 
 	if (*ifname) {
@@ -421,8 +422,10 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
 
 	if (dev->mac_specified)
 		dev->device_features |= (1ull << VIRTIO_NET_F_MAC);
-	else
+	else {
 		dev->device_features &= ~(1ull << VIRTIO_NET_F_MAC);
+		dev->unmask_features |= (1ull << VIRTIO_NET_F_MAC);
+	}
 
 	if (cq) {
 		/* device does not really need to know anything about CQ,
@@ -437,6 +440,12 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
 		dev->device_features &= ~(1ull << VIRTIO_NET_F_GUEST_ANNOUNCE);
 		dev->device_features &= ~(1ull << VIRTIO_NET_F_MQ);
 		dev->device_features &= ~(1ull << VIRTIO_NET_F_CTRL_MAC_ADDR);
+		dev->unmask_features |= (1ull << VIRTIO_NET_F_CTRL_VQ);
+		dev->unmask_features |= (1ull << VIRTIO_NET_F_CTRL_RX);
+		dev->unmask_features |= (1ull << VIRTIO_NET_F_CTRL_VLAN);
+		dev->unmask_features |= (1ull << VIRTIO_NET_F_GUEST_ANNOUNCE);
+		dev->unmask_features |= (1ull << VIRTIO_NET_F_MQ);
+		dev->unmask_features |= (1ull << VIRTIO_NET_F_CTRL_MAC_ADDR);
 	}
 
 	/* The backend will not report this feature, we add it explicitly */
@@ -444,6 +453,7 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
 		dev->device_features |= (1ull << VIRTIO_NET_F_STATUS);
 
 	dev->device_features &= VIRTIO_USER_SUPPORTED_FEATURES;
+	dev->unmask_features |= ~VIRTIO_USER_SUPPORTED_FEATURES;
 
 	if (rte_mem_event_callback_register(VIRTIO_USER_MEM_EVENT_CLB_NAME,
 				virtio_user_mem_event_cb, dev)) {
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.h b/drivers/net/virtio/virtio_user/virtio_user_dev.h
index d2d4cb825..a1da5f56c 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.h
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.h
@@ -33,6 +33,7 @@ struct virtio_user_dev {
 				   * and will be sync with device
 				   */
 	uint64_t	device_features; /* supported features by device */
+	uint64_t	unmask_features; /* unsupported features mask */
 	uint8_t		status;
 	uint16_t	port_id;
 	uint8_t		mac_addr[ETHER_ADDR_LEN];
diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
index 1c102ca72..0c02c6851 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -30,7 +30,6 @@ virtio_user_server_reconnect(struct virtio_user_dev *dev)
 	int ret;
 	int flag;
 	int connectfd;
-	uint64_t features = dev->device_features;
 	struct rte_eth_dev *eth_dev = &rte_eth_devices[dev->port_id];
 
 	connectfd = accept(dev->listenfd, NULL, NULL);
@@ -45,15 +44,8 @@ virtio_user_server_reconnect(struct virtio_user_dev *dev)
 		return -1;
 	}
 
-	features &= ~dev->device_features;
-	/* For following bits, vhost-user doesn't really need to know */
-	features &= ~(1ull << VIRTIO_NET_F_MAC);
-	features &= ~(1ull << VIRTIO_NET_F_CTRL_VLAN);
-	features &= ~(1ull << VIRTIO_NET_F_CTRL_MAC_ADDR);
-	features &= ~(1ull << VIRTIO_NET_F_STATUS);
-	if (features)
-		PMD_INIT_LOG(ERR, "WARNING: Some features 0x%" PRIx64 " are not supported by vhost-user!",
-			     features);
+	/* umask vhost-user unsupported features */
+	dev->device_features &= ~(dev->unmask_features);
 
 	dev->features &= dev->device_features;
 
-- 
2.17.0

Re: [dpdk-dev] [PATCH] net/virtio-user: add unsupported features mask

[Maxime Coquelin]

On 06/25/2018 03:10 PM, Marvin Liu wrote:
> This patch introduces unsupported features mask for virtio-user device.
> For virtio-user server mode, when reconnecting virtio-user will
> retrieve vhost devcie features as base and then unmask unsupported
s/devcie/device/
> features.

I am not sure to understand why you are doing it like this.

Shouldn't you just:
  1. Don't advertise features you don't want to support
  2. In server mode, save the negotiated features, and re-use it when
     reconnect happens?

Also, I find "unmask" a bit misleading, why not something like "unsupp"
or "unsupported"?

Thanks,
Maxime

Re: [dpdk-dev] [PATCH] net/virtio-user: add unsupported features mask

[Liu, Yong]

> -----Original Message-----
> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> Sent: Tuesday, June 26, 2018 4:08 PM
> To: Liu, Yong <yong.liu@intel.com>; Bie, Tiwei <tiwei.bie@intel.com>
> Cc: Wang, Zhihong <zhihong.wang@intel.com>; dev@dpdk.org
> Subject: Re: [PATCH] net/virtio-user: add unsupported features mask
> 
> 
> 
> On 06/25/2018 03:10 PM, Marvin Liu wrote:
> > This patch introduces unsupported features mask for virtio-user device.
> > For virtio-user server mode, when reconnecting virtio-user will
> > retrieve vhost devcie features as base and then unmask unsupported
> s/devcie/device/
> > features.
> 
> I am not sure to understand why you are doing it like this.
> 
> Shouldn't you just:
>   1. Don't advertise features you don't want to support
>   2. In server mode, save the negotiated features, and re-use it when
>      reconnect happens?
> 
Maxime,
I think our vhost reconnect design is following qemu vhost-user server mode. Virtio-user will try to support connected vhost device.
So device_features of virtio user just retrieve from vhost device. 
And in server mode, we have recorded previous feature bits and used it for later negotiation. But virtio user device_features which may has changed by vdev parameters. This mask will guaranty device_features correct.

Thanks,
Marvin

> Also, I find "unmask" a bit misleading, why not something like "unsupp"
> or "unsupported"?
> 
> Thanks,
> Maxime

Re: [dpdk-dev] [PATCH] net/virtio-user: add unsupported features mask

[Maxime Coquelin]

On 06/26/2018 11:02 AM, Liu, Yong wrote:
> 
> 
>> -----Original Message-----
>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>> Sent: Tuesday, June 26, 2018 4:08 PM
>> To: Liu, Yong <yong.liu@intel.com>; Bie, Tiwei <tiwei.bie@intel.com>
>> Cc: Wang, Zhihong <zhihong.wang@intel.com>; dev@dpdk.org
>> Subject: Re: [PATCH] net/virtio-user: add unsupported features mask
>>
>>
>>
>> On 06/25/2018 03:10 PM, Marvin Liu wrote:
>>> This patch introduces unsupported features mask for virtio-user device.
>>> For virtio-user server mode, when reconnecting virtio-user will
>>> retrieve vhost devcie features as base and then unmask unsupported
>> s/devcie/device/
>>> features.
>>
>> I am not sure to understand why you are doing it like this.
>>
>> Shouldn't you just:
>>    1. Don't advertise features you don't want to support
>>    2. In server mode, save the negotiated features, and re-use it when
>>       reconnect happens?
>>
> Maxime,
> I think our vhost reconnect design is following qemu vhost-user server mode. Virtio-user will try to support connected vhost device.
> So device_features of virtio user just retrieve from vhost device.
> And in server mode, we have recorded previous feature bits and used it for later negotiation. But virtio user device_features which may has changed by vdev parameters. This mask will guaranty device_features correct.

Ok, get it now, thanks for the clarification.

Please reword the variable name as I proposed, and pick this patch
directly in your in_order series.

With name change, feel free to add:
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>

Thanks,
Maxime

> Thanks,
> Marvin
> 
>> Also, I find "unmask" a bit misleading, why not something like "unsupp"
>> or "unsupported"?
>>
>> Thanks,
>> Maxime