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:   Sat, 30 Mar 2019 12:49:23 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Jiri Pirko <jiri@...nulli.us>
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

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 :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ