From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 462A7C433ED for ; Mon, 12 Apr 2021 23:54:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 16C2F61244 for ; Mon, 12 Apr 2021 23:54:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242649AbhDLXzL (ORCPT ); Mon, 12 Apr 2021 19:55:11 -0400 Received: from mail.nic.cz ([217.31.204.67]:58582 "EHLO mail.nic.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237250AbhDLXzK (ORCPT ); Mon, 12 Apr 2021 19:55:10 -0400 Received: from thinkpad (unknown [IPv6:2a0e:b107:ae1:0:3e97:eff:fe61:c680]) by mail.nic.cz (Postfix) with ESMTPSA id 949C0140655; Tue, 13 Apr 2021 01:54:50 +0200 (CEST) Date: Tue, 13 Apr 2021 01:54:50 +0200 From: Marek Behun To: Tobias Waldekranz Cc: Vladimir Oltean , Ansuel Smith , netdev@vger.kernel.org, "David S. Miller" , Jakub Kicinski , Andrew Lunn , Vivien Didelot , Florian Fainelli , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eric Dumazet , Wei Wang , Cong Wang , Taehee Yoo , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , zhang kai , Weilong Chen , Roopa Prabhu , Di Zhu , Francis Laniel , linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support Message-ID: <20210413015450.1ae597da@thinkpad> In-Reply-To: <87o8ejjdu6.fsf@waldekranz.com> References: <20210410133454.4768-1-ansuelsmth@gmail.com> <20210411200135.35fb5985@thinkpad> <20210411185017.3xf7kxzzq2vefpwu@skbuf> <878s5nllgs.fsf@waldekranz.com> <20210412213045.4277a598@thinkpad> <8735vvkxju.fsf@waldekranz.com> <20210412235054.73754df9@thinkpad> <87wnt7jgzk.fsf@waldekranz.com> <20210413005518.2f9b9cef@thinkpad> <87r1jfje26.fsf@waldekranz.com> <87o8ejjdu6.fsf@waldekranz.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 13 Apr 2021 01:13:53 +0200 Tobias Waldekranz wrote: > > ...you could get the isolation in place. But you will still lookup the > > DA in the ATU, and there you will find a destination of either cpu0 or > > cpu1. So for one of the ports, the destination will be outside of its > > port based VLAN. Once the vectors are ANDed together, it is left with no > > valid port to egress through, and the packet is dropped. > > > >> Am I wrong? I confess that I did not understand this into the most fine > >> details, so it is entirely possible that I am missing something > >> important and am completely wrong. Maybe this cannot be done. > > > > I really doubt that it can be done. Not in any robust way at > > least. Happy to be proven wrong though! :) > > I think I figured out why it "works" for you. Since the CPU address is > never added to the ATU, traffic for it is treated as unknown. Thanks to > that, it flooded and the isolation brings it together. As soon as > mv88e6xxx starts making use of Vladimirs offloading of host addresses > though, I suspect this will fall apart. Hmm :( This is bad news. I would really like to make it balance via input ports. The LAG balancing for this usecase is simply unacceptable, since the switch puts so little information into the hash function. I will look into this, maybe ask some follow-up questions. Marek