From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f195.google.com ([209.85.128.195]:46357 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751294AbeCWGe2 (ORCPT ); Fri, 23 Mar 2018 02:34:28 -0400 Received: by mail-wr0-f195.google.com with SMTP id s10so10947722wra.13 for ; Thu, 22 Mar 2018 23:34:27 -0700 (PDT) Date: Fri, 23 Mar 2018 07:34:26 +0100 From: Jiri Pirko To: David Ahern Cc: 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, gospo@broadcom.com, sathya.perla@broadcom.com, vasundhara-v.volam@broadcom.com, tariqt@mellanox.com, eranbe@mellanox.com, jeffrey.t.kirsher@intel.com Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation Message-ID: <20180323063426.GK2074@nanopsycho.orion> References: <20180322105522.8186-1-jiri@resnulli.us> <7217d1fb-665f-92cf-2704-364b91cb8248@gmail.com> <20180322174904.GG2074@nanopsycho.orion> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Thu, Mar 22, 2018 at 08:10:38PM CET, dsahern@gmail.com 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. So you say that we need to enforce it somehow? > >> >> >>> >>>> >>>> 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. Ok