From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation Date: Thu, 17 May 2018 10:47:15 +0200 Message-ID: <20180517084715.GR1972@nanopsycho> References: <20180322105522.8186-1-jiri@resnulli.us> <7217d1fb-665f-92cf-2704-364b91cb8248@gmail.com> <20180322174904.GG2074@nanopsycho.orion> <20180322192546.GA55631@C02RW35GFVH8.dhcp.broadcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Ahern , netdev@vger.kernel.org, davem@davemloft.net, idosch@mellanox.com, jakub.kicinski@netronome.com, mlxsw@mellanox.com, andrew@lunn.ch, vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com, michael.chan@broadcom.com, ganeshgr@chelsio.com, saeedm@mellanox.com, simon.horman@netronome.com, pieter.jansenvanvuuren@netronome.com, john.hurley@netronome.com, dirk.vandermerwe@netronome.com, alexander.h.duyck@intel.com, ogerlitz@mellanox.com, vijaya.guvva@cavium.com, satananda.burla@cavium.com, raghu.vatsavayi@cavium.com, felix.manlunas@cavium.com, sathya.perla@broadcom.com, vasundhara-v.volam@broadcom.com, tariqt@mellanox.com, eranbe@mellanox.com, jeffrey.t.kirsher@intel.com To: Andy Gospodarek Return-path: Received: from mail-wm0-f67.google.com ([74.125.82.67]:55913 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751396AbeEQIrS (ORCPT ); Thu, 17 May 2018 04:47:18 -0400 Received: by mail-wm0-f67.google.com with SMTP id a8-v6so6942132wmg.5 for ; Thu, 17 May 2018 01:47:17 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20180322192546.GA55631@C02RW35GFVH8.dhcp.broadcom.net> Sender: netdev-owner@vger.kernel.org List-ID: Thu, Mar 22, 2018 at 08:25:46PM CET, andrew.gospodarek@broadcom.com wrote: >On Thu, Mar 22, 2018 at 01:10:38PM -0600, David Ahern wrote: >> On 3/22/18 11:49 AM, Jiri Pirko wrote: >> > Thu, Mar 22, 2018 at 04:34:07PM CET, dsahern@gmail.com wrote: >> >> On 3/22/18 4:55 AM, Jiri Pirko wrote: >> >>> From: Jiri Pirko >> >>> >> >>> This patchset resolves 2 issues we have right now: >> >>> 1) There are many netdevices / ports in the system, for port, pf, vf >> >>> represenatation but the user has no way to see which is which >> >>> 2) The ndo_get_phys_port_name is implemented in each driver separatelly, >> >>> which may lead to inconsistent names between drivers. >> >> >> >> Similar to ndo_get_phys_port_{name,id}, devlink requires drivers to opt >> >> in with an implementation right, so you can't really force a solution to >> >> the consistent naming. >> > >> > Yeah, drivers would still have free choice to implemen the ndo >> > themselves. But most of them, like all sriov switch drivers should use >> > the devlink helper to have consistent naming. In other words, devlink >> > helper should be the standard way, in weird cases (like rocker), driver >> > implements it himself. >> >> That's an assumption that somehow the devlink API will be better >> supported than ndo_get_phys_port_{name,id}. Don't get me wrong -- an API >> to show the kind of device is needed, but I do not think this enforces >> any kind of consistency in naming. >> >> > >> > >> >> >> >>> >> >>> This patchset introduces port flavours which should address the first >> >>> problem. I'm testing this with Netronome nfp hardware. When the user >> >>> has 2 physical ports, 1 pf, and 4 vfs, he should see something like this: >> >>> # devlink port >> >>> pci/0000:05:00.0/0: type eth netdev enp5s0np0 flavour physical number 0 >> >>> pci/0000:05:00.0/268435456: type eth netdev eth0 flavour physical number 0 >> >>> pci/0000:05:00.0/268435460: type eth netdev enp5s0np1 flavour physical number 1 >> >>> pci/0000:05:00.0/536875008: type eth netdev eth2 flavour pf_rep number 536875008 >> >>> pci/0000:05:00.0/536870912: type eth netdev eth1 flavour vf_rep number 0 >> >>> pci/0000:05:00.0/536870976: type eth netdev eth3 flavour vf_rep number 1 >> >>> pci/0000:05:00.0/536871040: type eth netdev eth4 flavour vf_rep number 2 >> >>> pci/0000:05:00.0/536871104: type eth netdev eth5 flavour vf_rep number 3 >> >> >> >> How about 'kind' instead of flavo{u}r? >> > >> > Yeah, kind is often used in kernel already with different meaning >> > git grep kind net/core >> > I wanted to avoid confusions >> >> Roopa's amendment works as well; I just think flavor / flavour is the >> wrong word. Make me thinks of food ... ice cream vs netdevices. > >Naming it a 'subtype' could also work. It's a bit longer than 'kind' >(no longer than 'flavour') and accurately describes the characteristic >of this port. It also avoids the namespace collision of 'kind' that >Jiri points out. > >It also fits with the names used in the PCI world with vendor:device and >subsystem vendor:subsystem device naming used there for further >granularity. Problem with "subtype" is that it indicates some relation with type. We have type: enum devlink_port_type { DEVLINK_PORT_TYPE_NOTSET, DEVLINK_PORT_TYPE_AUTO, DEVLINK_PORT_TYPE_ETH, DEVLINK_PORT_TYPE_IB, }; Does not feel correct to have subtypes VF/PF/VFREP/etc, which really has no relation to ETH/IB What about "role"? Also does not sound good to me, as the "role" indicates that the port can "act" like something. For me the "flavour/flavor" is still a favourite. Tells how the port tastes like, in a semi-fun way :) Also, there is a precedence to this in particle physics: https://en.wikipedia.org/wiki/Color%E2%80%93flavor_locking I guess they also had troubles to find the right name :) >