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
| ||
|
Date: Mon, 23 May 2022 14:53:13 -0700 From: Florian Fainelli <f.fainelli@...il.com> To: Vladimir Oltean <olteanv@...il.com>, netdev@...r.kernel.org Cc: Jakub Kicinski <kuba@...nel.org>, Vivien Didelot <vivien.didelot@...il.com>, Andrew Lunn <andrew@...n.ch>, Tobias Waldekranz <tobias@...dekranz.com>, Marek Behún <kabel@...nel.org>, Ansuel Smith <ansuelsmth@...il.com>, DENG Qingfang <dqfext@...il.com>, Alvin Šipraga <alsi@...g-olufsen.dk>, Claudiu Manoil <claudiu.manoil@....com>, Alexandre Belloni <alexandre.belloni@...tlin.com>, UNGLinuxDriver@...rochip.com, Colin Foster <colin.foster@...advantage.com>, Linus Walleij <linus.walleij@...aro.org>, Luiz Angelo Daros de Luca <luizluca@...il.com>, Roopa Prabhu <roopa@...dia.com>, Nikolay Aleksandrov <razor@...ckwall.org>, Frank Wunderlich <frank-w@...lic-files.de>, Vladimir Oltean <vladimir.oltean@....com> Subject: Re: [RFC PATCH net-next 00/12] DSA changes for multiple CPU ports (part 3) On 5/23/22 03:42, Vladimir Oltean wrote: > From: Vladimir Oltean <vladimir.oltean@....com> > > Note: this patch set isn't probably tested nearly well enough, and > contains (at least minor) bugs. Don't do crazy things with it. I'm > posting it to get feedback on the proposed UAPI. > > Those who have been following part 1: > https://patchwork.kernel.org/project/netdevbpf/cover/20220511095020.562461-1-vladimir.oltean@nxp.com/ > and part 2: > https://patchwork.kernel.org/project/netdevbpf/cover/20220521213743.2735445-1-vladimir.oltean@nxp.com/ > will know that I am trying to enable the second internal port pair from > the NXP LS1028A Felix switch for DSA-tagged traffic via "ocelot-8021q". > This series represents part 3 of that effort. > > Covered here are some code structure changes so that DSA monitors > changeupper events of its masters, as well as new UAPI introduction via > rtnetlink for changing the current master. Note, in the case of a LAG > DSA master, DSA user ports can be assigned to the LAG in 2 ways, either > through this new IFLA_DSA_MASTER, or simply when their existing DSA > master joins a LAG. > > Compared to previous attempts to introduce support for multiple CPU ports: > https://lore.kernel.org/netdev/20210410133454.4768-1-ansuelsmth@gmail.com/ > > my proposal is to not change anything in the default behavior (i.e. > still start off with the first CPU port from the device tree as the only > active CPU port). But focus is instead put on being able to live-change > what the user-to-CPU-port affinity is. Marek Behun has expressed a > potential use case as being to dynamically load balance the termination > of ports between CPU ports, and that should be best handled by a user > space daemon if it only had the means - this creates the means. > > Host address filtering is interesting with multiple CPU ports. > There are 2 types of host filtered addresses to consider: > - standalone MAC addresses of ports. These are either inherited from the > respective DSA masters of the ports, or from the device tree blob. > - local bridge FDB entries. > > Traditionally, DSA manages host-filtered addresses by calling > port_fdb_add(dp->cpu_dp->index) in the appropriate database. > But for example, when we have 2 bridged DSA user ports, one with CPU > port A and the other with CPU port B, and the bridge offloads a local > FDB entry for 00:01:02:03:04:05, DSA would attempt to first call > port_fdb_add(A, 00:01:02:03:04:05, DSA_DB_BRIDGE), then > port_fdb_add(B, 00:01:02:03:04:05, DSA_DB_BRIDGE). And since an FDB > entry can have a single destination, the second port_fdb_add() > overwrites the first one, and locally terminated traffic for the ports > assigned to CPU port A is broken. > > What should be done in that situation, at least with the HW I'm working > with, is that the host filtered addresses should be delivered towards a > "multicast" destination that covers both CPU ports, and let the > forwarding matrix eliminate the CPU port that the current user port > isn't affine to. > > In my proposed patch set, the Felix driver does exactly that: host > filtered addresses are learned towards a special PGID_CPU that has both > tag_8021q CPU ports as destinations. > > I have considered introducing new dsa_switch_ops API in the form of > host_fdb_add(user port) and host_fdb_del(user port) rather than calling > port_fdb_add(cpu port). After all, this would be similar to the newly > introduced port_set_host_flood(user port). But I need to think a bit > more whether it's needed right away. > > Finally, there's LAG. Proposals have been made before to describe in DT > that CPU ports are under a LAG, the idea being that we could then do the > same for DSA (cascade) ports. The common problem is that shared (CPU and > DSA) ports have no netdev exposed. > > I didn't do that, instead I went for the more natural approach of saying > that if the CPU ports are in a LAG, then the DSA masters are in a > symmetric LAG as well. So why not just monitor when the DSA masters join > a LAG, and piggyback on that configuration and make DSA reconfigure > itself accordingly. > > So LAG devices can now be DSA masters, and this is accomplished by > populating their dev->dsa_ptr. Note that we do not create a specific > struct dsa_port to populate their dsa_ptr, instead we reuse the dsa_ptr > of one of the physical DSA masters (the first one, in fact). This looks pretty good to me and did not blow up with bcm_sf2 not implementing port_change_master, so far so good. -- Florian
Powered by blists - more mailing lists