On Mon, Aug 9, 2021 at 2:10 PM Parav Pandit <parav@xxxxxxxxxx> wrote:
>
>
>
> > From: Eli Cohen <elic@xxxxxxxxxx>
> > 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@xxxxxxxxxx>
> > > > 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@xxxxxxxxxx>
> > > > > > 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@xxxxxxxxxx>
> > > > > > > > > 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@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
