Hi Alex, > -----Original Message----- > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > Sent: Friday, September 13, 2019 4:33 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 v3 0/5] Introduce variable length mdev alias > > On Wed, 11 Sep 2019 16:38:49 +0000 > Parav Pandit <parav@xxxxxxxxxxxx> wrote: > > > > -----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 > > Jiri may have agreed to the concept, but without patches on the list proving an > end to end solution, I think it's too early for us to commit to this by > preemptively adding it to our API. "Acked" and "collective agreement" seem > like they overstate something that seems not to have seen the light of day yet. > Instead I'll say, it looks reasonable, come back when the real consumer has > actually been proposed upstream and has more buy-in from the community > and we'll see if it still looks like the right approach from an mdev perspective > then. Thanks, > Ok. I will combine these patches with the actual consumer patches of mdev_alias(). Thanks. > Alex
