netdev - Re: [patch net-next 00/12] net: expose switch ID via devlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 31 Mar 2019 10:50:17 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>, mlxsw@...lanox.com,
        Ido Schimmel <idosch@...lanox.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>, vivien.didelot@...il.com,
        Michael Chan <michael.chan@...adcom.com>,
        Or Gerlitz <ogerlitz@...lanox.com>
Subject: Re: [patch net-next 00/12] net: expose switch ID via devlink

Sat, Mar 30, 2019 at 08:49:23PM CET, jakub.kicinski@...ronome.com wrote:
>On Sat, 30 Mar 2019 08:35:27 +0100, Jiri Pirko wrote:
>>> Is switchib doing forwarding?  Not long ago Parav was convincing us
>>> that switchdev mode for IB is pretty much meaningless.  Even though
>>> there are apparently representors for IB (judging by the recent RDMA
>>> patchset on netdev)...  
>> 
>> Switch id is simply identifier for ports in general that belong to some
>> switch. No matter if ethernet or IB.
>
>IIUC functionally there are two uses for switch ID:
> (1) bridging code and flower offloads making forwarding decisions;
> (2) naming the netdevs of the same switch with udev rules (sw$id$port).
>Meta use:
> - logically grouping netdevs so that user space knows how (1) and (2)
>   will behave.
>
>Devlink ports are already grouped under the devlink instance, and they
>not involved in forwarding decisions.
>
>We should add functionality when we have evidence it's going to be
>useful.  I don't see how devlink needs switch id, in any way.  Sure,
>the internal code reshuffle is a matter of taste, but for exposing
>switch id on devlink ports, I see _no_ reason.
>
>I think this makes my position clear :)  I don't really enjoy
>disagreeing with people, and neither do I care about this particularly
>strongly, so please consider what I said, and if that doesn't convince
>you feel free to add my review tag on the nfp patches :)

I understand that from the functionality point of view, you are correct.
But for the visibility and better understanding about what's the
topology, I think it would be fine to expose this. Anyway, I'll remove
the patch to expose the devlink ATTR for now. Let's see how things are
going to look after we do the rest.