Parav Pandit
2021-Aug-09 06:10 UTC
[PATCH linux-next v3 0/6] vdpa: enable user to set mac, mtu
> From: Eli Cohen <elic at nvidia.com> > Sent: Monday, August 9, 2021 11:38 AM > > On Mon, Aug 09, 2021 at 09:01:48AM +0300, Parav Pandit wrote: > > > > > > > From: Eli Cohen <elic at nvidia.com> > > > Sent: Monday, August 9, 2021 11:28 AM > > > > > > On Mon, Aug 09, 2021 at 08:42:58AM +0300, Parav Pandit wrote: > > > > > > > > > > > > > From: Eli Cohen <elic at nvidia.com> > > > > > 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 at 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 guranteeHence 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().
Jason Wang
2021-Aug-09 07:05 UTC
[PATCH linux-next v3 0/6] vdpa: enable user to set mac, mtu
On Mon, Aug 9, 2021 at 2:10 PM Parav Pandit <parav at nvidia.com> wrote:> > > > > From: Eli Cohen <elic at nvidia.com> > > Sent: Monday, August 9, 2021 11:38 AM > > > > On Mon, Aug 09, 2021 at 09:01:48AM +0300, Parav Pandit wrote: > > > > > > > > > > From: Eli Cohen <elic at nvidia.com> > > > > Sent: Monday, August 9, 2021 11:28 AM > > > > > > > > On Mon, Aug 09, 2021 at 08:42:58AM +0300, Parav Pandit wrote: > > > > > > > > > > > > > > > > From: Eli Cohen <elic at nvidia.com> > > > > > > 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 at 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