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: Sun, 11 Apr 2021 19:07:08 -0700 From: Florian Fainelli <f.fainelli@...il.com> To: Andrew Lunn <andrew@...n.ch>, Marek Behun <marek.behun@....cz> Cc: Ansuel Smith <ansuelsmth@...il.com>, netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Vivien Didelot <vivien.didelot@...il.com>, Vladimir Oltean <olteanv@...il.com>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andriin@...com>, Eric Dumazet <edumazet@...gle.com>, Wei Wang <weiwan@...gle.com>, Cong Wang <cong.wang@...edance.com>, Taehee Yoo <ap420073@...il.com>, Björn Töpel <bjorn@...nel.org>, zhang kai <zhangkaiheb@....com>, Weilong Chen <chenweilong@...wei.com>, Roopa Prabhu <roopa@...ulusnetworks.com>, Di Zhu <zhudi21@...wei.com>, Francis Laniel <laniel_francis@...vacyrequired.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support On 4/11/2021 11:39 AM, Andrew Lunn wrote: > On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote: >> On Sat, 10 Apr 2021 15:34:46 +0200 >> Ansuel Smith <ansuelsmth@...il.com> wrote: >> >>> Hi, >>> this is a respin of the Marek series in hope that this time we can >>> finally make some progress with dsa supporting multi-cpu port. >>> >>> This implementation is similar to the Marek series but with some tweaks. >>> This adds support for multiple-cpu port but leave the driver the >>> decision of the type of logic to use about assigning a CPU port to the >>> various port. The driver can also provide no preference and the CPU port >>> is decided using a round-robin way. >> >> In the last couple of months I have been giving some thought to this >> problem, and came up with one important thing: if there are multiple >> upstream ports, it would make a lot of sense to dynamically reallocate >> them to each user port, based on which user port is actually used, and >> at what speed. >> >> For example on Turris Omnia we have 2 CPU ports and 5 user ports. All >> ports support at most 1 Gbps. Round-robin would assign: >> CPU port 0 - Port 0 >> CPU port 1 - Port 1 >> CPU port 0 - Port 2 >> CPU port 1 - Port 3 >> CPU port 0 - Port 4 >> >> Now suppose that the user plugs ethernet cables only into ports 0 and 2, >> with 1, 3 and 4 free: >> CPU port 0 - Port 0 (plugged) >> CPU port 1 - Port 1 (free) >> CPU port 0 - Port 2 (plugged) >> CPU port 1 - Port 3 (free) >> CPU port 0 - Port 4 (free) >> >> We end up in a situation where ports 0 and 2 share 1 Gbps bandwidth to >> CPU, and the second CPU port is not used at all. >> >> A mechanism for automatic reassignment of CPU ports would be ideal here. > > One thing you need to watch out for here source MAC addresses. I've > not looked at the details, so this is more a heads up, it needs to be > thought about. > > DSA slaves get there MAC address from the master interface. For a > single CPU port, all the slaves have the same MAC address. What > happens when you have multiple CPU ports? Does the slave interface get > the MAC address from its CPU port? It seems to be addressed by this part of patch 2: + if (ether_addr_equal(dev->dev_addr, master->dev_addr)) + eth_hw_addr_inherit(dev, cpu_dev); although this could create an interesting set of issues if done fully dynamically while the data path is active. > What happens when a slave moves > from one CPU interface to another CPU interface? Does its MAC address > change. ARP is going to be unhappy for a while? Also, how is the > switch deciding on which CPU port to use? Some switches are probably > learning the MAC address being used by the interface and doing > forwarding based on that. So you might need unique slave MAC > addresses, and when a slave moves, it takes it MAC address with it, > and you hope the switch learns about the move. But considered trapped > frames as opposed to forwarded frames. So BPDU, IGMP, etc. Generally, > you only have the choice to send such trapped frames to one CPU > port. So potentially, such frames are going to ingress on the wrong > port. Does this matter? What about multicast? How do you control what > port that ingresses on? What about RX filters on the master > interfaces? Could it be we added it to the wrong master? > > For this series to make progress, we need to know what has been > tested, and if all the more complex functionality works, not just > basic pings. Agreed. -- Florian
Powered by blists - more mailing lists