[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180322174904.GG2074@nanopsycho.orion>
Date: Thu, 22 Mar 2018 18:49:04 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: David Ahern <dsahern@...il.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com,
jakub.kicinski@...ronome.com, mlxsw@...lanox.com, andrew@...n.ch,
vivien.didelot@...oirfairelinux.com, f.fainelli@...il.com,
michael.chan@...adcom.com, ganeshgr@...lsio.com,
saeedm@...lanox.com, simon.horman@...ronome.com,
pieter.jansenvanvuuren@...ronome.com, john.hurley@...ronome.com,
dirk.vandermerwe@...ronome.com, alexander.h.duyck@...el.com,
ogerlitz@...lanox.com, vijaya.guvva@...ium.com,
satananda.burla@...ium.com, raghu.vatsavayi@...ium.com,
felix.manlunas@...ium.com, gospo@...adcom.com,
sathya.perla@...adcom.com, vasundhara-v.volam@...adcom.com,
tariqt@...lanox.com, eranbe@...lanox.com,
jeffrey.t.kirsher@...el.com
Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and
common phys_port_name generation
Thu, Mar 22, 2018 at 04:34:07PM CET, dsahern@...il.com wrote:
>On 3/22/18 4:55 AM, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@...lanox.com>
>>
>> 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.
>
>>
>> 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
>
Powered by blists - more mailing lists