From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com ([74.125.82.41]:54303 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753578AbeCVO6I (ORCPT ); Thu, 22 Mar 2018 10:58:08 -0400 Received: by mail-wm0-f41.google.com with SMTP id h76so16571306wme.4 for ; Thu, 22 Mar 2018 07:58:07 -0700 (PDT) Date: Thu, 22 Mar 2018 15:58:05 +0100 From: Jiri Pirko To: Roopa Prabhu Cc: netdev@vger.kernel.org, David Miller , Ido Schimmel , Jakub Kicinski , mlxsw , Andrew Lunn , Vivien Didelot , Florian Fainelli , Michael Chan , ganeshgr@chelsio.com, Saeed Mahameed , Simon Horman , pieter.jansenvanvuuren@netronome.com, John Hurley , Dirk van der Merwe , Alexander Duyck , Or Gerlitz , David Ahern , vijaya.guvva@cavium.com, satananda.burla@cavium.com, raghu.vatsavayi@cavium.com, felix.manlunas@cavium.com, Andy Gospodarek , sathya.perla@broadcom.com, vasundhara-v.volam@broadcom.com, tariqt@mellanox.com, eranbe@mellanox.com, Jeff Kirsher Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation Message-ID: <20180322145805.GE2074@nanopsycho.orion> References: <20180322105522.8186-1-jiri@resnulli.us> 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 03:40:02PM CET, roopa@cumulusnetworks.com wrote: >On Thu, Mar 22, 2018 at 3: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. >> >> 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 >> >> The indexes are weird numbers now. That needs to be fixed. Also, netdev >> renaming does not work correctly for me now for some reason. >> Also, there is one extra port that I don't understand what >> is the purpose for it - something nfp specific perhaps. >> >> The desired output should look like this: >> # devlink port >> pci/0000:05:00.0/0: type eth netdev enp5s0np0 flavour physical number 0 >> pci/0000:05:00.0/1: type eth netdev enp5s0np1 flavour physical number 1 >> pci/0000:05:00.0/2: type eth netdev enp5s0npf0 flavour pf_rep number 0 >> pci/0000:05:00.0/3: type eth netdev enp5s0nvf0 flavour vf_rep number 0 >> pci/0000:05:00.0/4: type eth netdev enp5s0nvf1 flavour vf_rep number 1 >> pci/0000:05:00.0/5: type eth netdev enp5s0nvf2 flavour vf_rep number 2 >> pci/0000:05:00.0/6: type eth netdev enp5s0nvf3 flavour vf_rep number 3 >> >> As you can see, the netdev names are generated according to the flavour >> and port number. In case the port is split, the split subnumber is also >> included. >> >> I tested this for mlxsw and nfp. I have no way to test this on DSA hw, >> I would really appretiate DSA guys to test this. Thanks! >> > >nice series, I like that the user can query a ports flavor (I get this >ask all the time). Yeah, it is really needed. I would like to fix this jungle so all drivers behave the same. Started with nfp as they are leading with what they have implemented. But I expect others to join in (please). Many drivers just create devlink instance without any ports. Odd. I will write some Documentation file as a part of this patchset. Also, I'm thinking about adding some warnings in care driver does some crippled implementation.