> -----Original Message----- > From: linux-kernel-owner@xxxxxxxxxxxxxxx <linux-kernel- > owner@xxxxxxxxxxxxxxx> On Behalf Of Parav Pandit > Sent: Wednesday, September 11, 2019 10:31 AM > To: Alex Williamson <alex.williamson@xxxxxxxxxx> > Cc: Jiri Pirko <jiri@xxxxxxxxxxxx>; kwankhede@xxxxxxxxxx; > cohuck@xxxxxxxxxx; davem@xxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx > Subject: RE: [PATCH v3 0/5] Introduce variable length mdev alias > > Hi Alex, > > > -----Original Message----- > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > Sent: Wednesday, September 11, 2019 8:56 AM > > 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 v3 0/5] Introduce variable length mdev alias > > > > On Mon, 9 Sep 2019 20:42:32 +0000 > > Parav Pandit <parav@xxxxxxxxxxxx> wrote: > > > > > Hi Alex, > > > > > > > -----Original Message----- > > > > From: Parav Pandit <parav@xxxxxxxxxxxx> > > > > Sent: Sunday, September 1, 2019 11:25 PM > > > > 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 v3 0/5] 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, update > > > > Documentation > > > > Patch-4 Introduces mdev_alias() API. > > > > Patch-5 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. > > > > > > > > [1] http://man7.org/linux/man-pages/man8/devlink-port.8.html > > > > [2] https://docs.openstack.org/os-vif/latest/user/plugins/ovs.html > > > > [3] https://patchwork.kernel.org/cover/11084231/ > > > > > > > > --- > > > > Changelog: > > > > v2->v3: > > > > - Addressed comment from Yunsheng Lin > > > > - Changed strcmp() ==0 to !strcmp() > > > > - Addressed comment from Cornelia Hunk > > > > - Merged sysfs Documentation patch with syfs patch > > > > - Added more description for alias return value > > > > > > Did you get a chance review this updated series? > > > I addressed Cornelia's and yours comment. > > > I do not think allocating alias memory twice, once for comparison > > > and once for storing is good idea or moving alias generation logic > > > inside the mdev_list_lock(). So I didn't address that suggestion of > Cornelia. > > > > Sorry, I'm at LPC this week. I agree, I don't think the double > > allocation is necessary, I thought the comment was sufficient to > > clarify null'ing the variable. It's awkward, but seems correct. > > > > I'm not sure what we do with this patch series though, has the real > > consumer of this even been proposed? Jiri already acked to use mdev_alias() to generate phys_port_name several days back in the discussion we had in [1]. After concluding in the thread [1], I proceed with mdev_alias(). mlx5_core patches are not yet present on netdev mailing list, but we all agree to use it in mdev_alias() in devlink phys_port_name generation. So we have collective agreement on how to proceed forward. I wasn't probably clear enough in previous email reply about it, so adding link here. [1] https://patchwork.kernel.org/cover/11084231/#22838955 > It feels optimistic to include > > at this point. We've used the sample driver as a placeholder in the > > past for mdev_uuid(), but we arrived at that via a conversion rather > > than explicitly adding the API. Please let me know where the consumer > > patches stand, perhaps it would make more sense for them to go in > > together rather than risk adding an unused API. Thanks, > > > Given that consumer patch series is relatively large (around 15+ patches), I > was considering to merge this one as pre-series to it. > Its ok to combine this with consumer patch series. > But wanted to have it reviewed beforehand, so that churn is less in actual > consumer series which is more mlx5_core and devlink/netdev centric. > So if you can add Review-by, it will be easier to combine with consumer > series. > > And if we merge it with consumer series, it will come through Dave Miller's > tree instead of your tree. > Would that work for you?
