RE: [PATCH linux-next v3 0/6] vdpa: enable user to set mac, mtu

quoted


From: Eli Cohen <redacted>
Sent: Monday, August 9, 2021 11:38 AM

On Mon, Aug 09, 2021 at 09:01:48AM +0300, Parav Pandit wrote:

From: Eli Cohen <redacted>
Sent: Monday, August 9, 2021 11:28 AM

On Mon, Aug 09, 2021 at 08:42:58AM +0300, Parav Pandit wrote:

From: Eli Cohen <redacted>
Sent: Monday, August 9, 2021 10:51 AM

On Mon, Aug 09, 2021 at 11:07:50AM +0800, Jason Wang wrote:
在 2021/8/6 下午4:55, Parav Pandit 写道:

From: Michael S. Tsirkin <mst@redhat.com>
Sent: Friday, August 6, 2021 2:12 PM

  enum vdpa_attr {
@@ -33,6 +34,16 @@ enum vdpa_attr {
  	VDPA_ATTR_DEV_MAX_VQS,			/* u32 */
  	VDPA_ATTR_DEV_MAX_VQ_SIZE,		/* u16 */
+	VDPA_ATTR_DEV_NET_CFG_MACADDR,
	/*
binary */
+	VDPA_ATTR_DEV_NET_STATUS,		/* u8
*/
+	VDPA_ATTR_DEV_NET_CFG_MAX_VQP,
	/*
u16 */
+	VDPA_ATTR_DEV_NET_CFG_MTU,		/*
u16 */
+	VDPA_ATTR_DEV_NET_CFG_SPEED,		/*
u16 */
+	VDPA_ATTR_DEV_NET_CFG_DUPLEX,		/*
u16 */
+	VDPA_ATTR_DEV_NET_CFG_RSS_MAX_KEY_LEN,
	/* u8
*/
+	VDPA_ATTR_DEV_NET_CFG_RSS_MAX_IT_LEN,
	/*
u16 */
+	VDPA_ATTR_DEV_NET_CFG_RSS_HASH_TYPES,
	/*
u32 */
+
  	/* new attributes must be added above here */
  	VDPA_ATTR_MAX,
  };
The point is to try and not reinvent a dedicated vpda
interface where a generic one exits.
E.g. for phy things such as mac speed etc, I think most
people are using ethtool things right?
As you know vdpa is the backend device for the front-end
netdevice
accessed by the ethtool.
vdpa management tool here is composing the vdpa device.

For example creator (hypervisor) of the vdpa devices knows
that a guest VM is given 4 vcpus, So hypervisor creates a
vdpa devices with config space layout as, max_virtqueue_pairs =
4.
And the MAC address chosen by hypervisor in mac[6].

Guest VM ethtool can still chose to use less number of channels.

Typically,
ethtool is for guest VM.
vdpa device is in hypevisor.

How can hypervisor compose a vdpa device without any tool?
How can it tell ethtool, what is supported and what are the
defaults?

Reread the cover letter:

"

This patchset enables users to set the mac address and mtu of
the vdpa device once the device is created.

"

It looks to me the mechanism that introduced in the series is
not for provisioning but for post-creation configuration?
The difference is subtle. In both cases you provide configuration.



I must be misunderstanding your comment about ethtool.
Can you please explain?

I guess the meaning is that, if the vDPA is assigned to guest,
it's the charge of guest to configure the MTU/MAC/RSS via the
existing management interface like ethtool/iproute2 netlink
protocol. The control virtqueue is designed for this.
I was under the impression that we want somehow to control the
capablity if the guest to use arbitrary MAC addresses.
If this is is not required than I think control VQ is the mechanism to
use.
How does the guest VM identify which unique mac address to set on
this
virtio net device when this is the only device in the VM?
Usually hypervisor knows what mac to set for a VM.
You don't need to know. You could use any MAC you want, if no one
else is using it in your subnet, and everything will work fine. The
point is do you want to allow the guest to choose its MAC. This has
implications of security.
Lets assume for a moment that a guest VM is able to program a MAC of
netdevice of virtio_device of net type.
How does a VM know that a randomly chosen mac is not used in network
when this VM doesn’t have any external connectivity?

There's no gurantee 
Hence a VF users, relies on the hypervisor to setup a unique MAC in the network.

And advance guest VM who has a device capable to modify the MAC (for bonding and other use) can override the mac.

So I don’t see them as mutually exclusive capability.

but it's being used all over and Linux has a specific API to
generate random MAC addresses: eth_hw_addr_random().
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Mon, Aug 9, 2021 at 2:10 PM Parav Pandit [off-list ref] wrote:


From: Eli Cohen <redacted>
Sent: Monday, August 9, 2021 11:38 AM

On Mon, Aug 09, 2021 at 09:01:48AM +0300, Parav Pandit wrote:

From: Eli Cohen <redacted>
Sent: Monday, August 9, 2021 11:28 AM

On Mon, Aug 09, 2021 at 08:42:58AM +0300, Parav Pandit wrote:

From: Eli Cohen <redacted>
Sent: Monday, August 9, 2021 10:51 AM

On Mon, Aug 09, 2021 at 11:07:50AM +0800, Jason Wang wrote:
在 2021/8/6 下午4:55, Parav Pandit 写道:

From: Michael S. Tsirkin <mst@redhat.com>
Sent: Friday, August 6, 2021 2:12 PM

  enum vdpa_attr {
@@ -33,6 +34,16 @@ enum vdpa_attr {
      VDPA_ATTR_DEV_MAX_VQS,                  /* u32 */
      VDPA_ATTR_DEV_MAX_VQ_SIZE,              /* u16 */
+     VDPA_ATTR_DEV_NET_CFG_MACADDR,
      /*
binary */
+     VDPA_ATTR_DEV_NET_STATUS,               /* u8
*/
+     VDPA_ATTR_DEV_NET_CFG_MAX_VQP,
      /*
u16 */
+     VDPA_ATTR_DEV_NET_CFG_MTU,              /*
u16 */
+     VDPA_ATTR_DEV_NET_CFG_SPEED,            /*
u16 */
+     VDPA_ATTR_DEV_NET_CFG_DUPLEX,           /*
u16 */
+     VDPA_ATTR_DEV_NET_CFG_RSS_MAX_KEY_LEN,
      /* u8
*/
+     VDPA_ATTR_DEV_NET_CFG_RSS_MAX_IT_LEN,
      /*
u16 */
+     VDPA_ATTR_DEV_NET_CFG_RSS_HASH_TYPES,
      /*
u32 */
+
      /* new attributes must be added above here */
      VDPA_ATTR_MAX,
  };
The point is to try and not reinvent a dedicated vpda
interface where a generic one exits.
E.g. for phy things such as mac speed etc, I think most
people are using ethtool things right?
As you know vdpa is the backend device for the front-end
netdevice
accessed by the ethtool.
vdpa management tool here is composing the vdpa device.

For example creator (hypervisor) of the vdpa devices knows
that a guest VM is given 4 vcpus, So hypervisor creates a
vdpa devices with config space layout as, max_virtqueue_pairs =
4.
And the MAC address chosen by hypervisor in mac[6].

Guest VM ethtool can still chose to use less number of channels.

Typically,
ethtool is for guest VM.
vdpa device is in hypevisor.

How can hypervisor compose a vdpa device without any tool?
How can it tell ethtool, what is supported and what are the
defaults?

Reread the cover letter:

"

This patchset enables users to set the mac address and mtu of
the vdpa device once the device is created.

"

It looks to me the mechanism that introduced in the series is
not for provisioning but for post-creation configuration?
The difference is subtle. In both cases you provide configuration.



I must be misunderstanding your comment about ethtool.
Can you please explain?

I guess the meaning is that, if the vDPA is assigned to guest,
it's the charge of guest to configure the MTU/MAC/RSS via the
existing management interface like ethtool/iproute2 netlink
protocol. The control virtqueue is designed for this.
I was under the impression that we want somehow to control the
capablity if the guest to use arbitrary MAC addresses.
If this is is not required than I think control VQ is the mechanism to
use.
How does the guest VM identify which unique mac address to set on
this
virtio net device when this is the only device in the VM?
Usually hypervisor knows what mac to set for a VM.
You don't need to know. You could use any MAC you want, if no one
else is using it in your subnet, and everything will work fine. The
point is do you want to allow the guest to choose its MAC. This has
implications of security.
Lets assume for a moment that a guest VM is able to program a MAC of
netdevice of virtio_device of net type.
How does a VM know that a randomly chosen mac is not used in network
when this VM doesn’t have any external connectivity?

There's no gurantee
Hence a VF users, relies on the hypervisor to setup a unique MAC in the network.

And advance guest VM who has a device capable to modify the MAC (for bonding and other use) can override the mac.

So I don’t see them as mutually exclusive capability.
Yes, we probably need both.

CVQ for post creation configuration and netlink API for provisioning.


but it's being used all over and Linux has a specific API to
generate random MAC addresses: eth_hw_addr_random().
Yes, but it uses local assignment bit, management may want use others.

Thanks

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Mon, Aug 09, 2021 at 03:05:31PM +0800, Jason Wang wrote:
So I don’t see them as mutually exclusive capability.
Yes, we probably need both.

CVQ for post creation configuration and netlink API for provisioning.
To note when host wants to change post provisioning it will also use
netlink I guess.


but it's being used all over and Linux has a specific API to
generate random MAC addresses: eth_hw_addr_random().
Yes, but it uses local assignment bit, management may want use others.

Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help

RE: [PATCH linux-next v3 0/6] vdpa: enable user to set mac, mtu

RE: [PATCH linux-next v3 0/6] vdpa: enable user to set mac, mtu

Re: [PATCH linux-next v3 0/6] vdpa: enable user to set mac, mtu

Re: [PATCH linux-next v3 0/6] vdpa: enable user to set mac, mtu