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  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 <>
To:     Jakub Kicinski <>
Cc:     Linux Netdev List <>,
        David Miller <>,,
        Ido Schimmel <>,
        Florian Fainelli <>,
        Andrew Lunn <>,,
        Michael Chan <>,
        Or Gerlitz <>
Subject: Re: [patch net-next 00/12] net: expose switch ID via devlink

Sat, Mar 30, 2019 at 08:49:23PM CET, 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.

Powered by blists - more mailing lists