From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation Date: Tue, 27 Mar 2018 22:02:34 -0700 Message-ID: <20180327220234.489a54fa@xeon-e3> References: <20180322105522.8186-1-jiri@resnulli.us> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, dsahern@gmail.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 To: Jiri Pirko Return-path: Received: from mail-pf0-f195.google.com ([209.85.192.195]:37375 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750732AbeC1FCi (ORCPT ); Wed, 28 Mar 2018 01:02:38 -0400 Received: by mail-pf0-f195.google.com with SMTP id t16so559945pfh.4 for ; Tue, 27 Mar 2018 22:02:38 -0700 (PDT) In-Reply-To: <20180322105522.8186-1-jiri@resnulli.us> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 22 Mar 2018 11:55:10 +0100 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 There already are a lot of attributes, adding more doesn't necessarily help make things clearer. > 2) The ndo_get_phys_port_name is implemented in each driver separatelly, > which may lead to inconsistent names between drivers. Why not address that problem. My concern is that your new attribute will have the same problem. Also adding pf and vfNNN on the name will make the already tightly squeezed interface name length a real problem. I have had arguments with people trying use VLAN 4000 and standard naming policy. Which means you really can't go that long.