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

[Jason Wang <jasowang@redhat.com>]

On Mon, Aug 9, 2021 at 2:10 PM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: Eli Cohen <elic@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@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@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@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