RE: [PATCH 0/4] Introduce variable length mdev alias

[Parav Pandit]

> -----Original Message-----
> From: Alex Williamson <alex.williamson@xxxxxxxxxx>
> Sent: Tuesday, August 27, 2019 11:19 PM
> To: Parav Pandit <parav@xxxxxxxxxxxx>
> Cc: Jiri Pirko <jiri@xxxxxxxxxxxx>; kwankhede@xxxxxxxxxx;
> cohuck@xxxxxxxxxx; davem@xxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 0/4] Introduce variable length mdev alias
> 
> On Tue, 27 Aug 2019 13:11:17 +0000
> Parav Pandit <parav@xxxxxxxxxxxx> wrote:
> 
> > Hi Alex, Cornelia,
> >
> > > -----Original Message-----
> > > From: kvm-owner@xxxxxxxxxxxxxxx <kvm-owner@xxxxxxxxxxxxxxx> On
> > > Behalf Of Parav Pandit
> > > Sent: Tuesday, August 27, 2019 2:11 AM
> > > To: alex.williamson@xxxxxxxxxx; Jiri Pirko <jiri@xxxxxxxxxxxx>;
> > > kwankhede@xxxxxxxxxx; cohuck@xxxxxxxxxx; davem@xxxxxxxxxxxxx
> > > Cc: kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > > netdev@xxxxxxxxxxxxxxx; Parav Pandit <parav@xxxxxxxxxxxx>
> > > Subject: [PATCH 0/4] Introduce variable length mdev alias
> > >
> > > To have consistent naming for the netdevice of a mdev and to have
> > > consistent naming of the devlink port [1] of a mdev, which is formed
> > > using phys_port_name of the devlink port, current UUID is not usable
> > > because UUID is too long.
> > >
> > > UUID in string format is 36-characters long and in binary 128-bit.
> > > Both formats are not able to fit within 15 characters limit of netdev
> name.
> > >
> > > It is desired to have mdev device naming consistent using UUID.
> > > So that widely used user space framework such as ovs [2] can make
> > > use of mdev representor in similar way as PCIe SR-IOV VF and PF
> representors.
> > >
> > > Hence,
> > > (a) mdev alias is created which is derived using sha1 from the mdev
> name.
> > > (b) Vendor driver describes how long an alias should be for the
> > > child mdev created for a given parent.
> > > (c) Mdev aliases are unique at system level.
> > > (d) alias is created optionally whenever parent requested.
> > > This ensures that non networking mdev parents can function without
> > > alias creation overhead.
> > >
> > > This design is discussed at [3].
> > >
> > > An example systemd/udev extension will have,
> > >
> > > 1. netdev name created using mdev alias available in sysfs.
> > >
> > > mdev UUID=83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
> > > mdev 12 character alias=cd5b146a80a5
> > >
> > > netdev name of this mdev = enmcd5b146a80a5 Here en = Ethernet link m
> > > = mediated device
> > >
> > > 2. devlink port phys_port_name created using mdev alias.
> > > devlink phys_port_name=pcd5b146a80a5
> > >
> > > This patchset enables mdev core to maintain unique alias for a mdev.
> > >
> > > Patch-1 Introduces mdev alias using sha1.
> > > Patch-2 Ensures that mdev alias is unique in a system.
> > > Patch-3 Exposes mdev alias in a sysfs hirerchy.
> > > Patch-4 Extends mtty driver to optionally provide alias generation.
> > > This also enables to test UUID based sha1 collision and trigger
> > > error handling for duplicate sha1 results.
> > >
> > > In future when networking driver wants to use mdev alias,
> > > mdev_alias() API will be added to derive devlink port name.
> > >
> > Now that majority of above patches looks in shape and I addressed all
> > comments, In next v1 post, I was considering to include mdev_alias()
> > and have example use in mtty driver.
> >
> > This way, subsequent series of mlx5_core who intents to use
> > mdev_alias() API makes it easy to review and merge through Dave M,
> > netdev tree. Is that ok with you?
> 
> What would be the timing for the mlx5_core use case?  Can we coordinate
> within the same development cycle?  I wouldn't want someone to come
> clean up the sample driver and remove the API ;)  Thanks,
> 
We targeted it for 5.4. mdev_alias was the only known user interface issue, which is resolved.
Some more internal reviews are in progress.
It might be tight for 5.4, if not 5.4, it should happen in 5.5.

I agree, that is why I was holding up to be part of this series.
Since its very small API, even if there is any merge conflict, it is easy to resolve.
If this change can be merged through netdev tree, its better to include it as part of mlx5_core's mdev series.
So both options are fine, a direction from you is better to have.