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.3 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 97C66C433B4 for ; Wed, 14 Apr 2021 15:14:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 74DA8613BB for ; Wed, 14 Apr 2021 15:14:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350408AbhDNPPE (ORCPT ); Wed, 14 Apr 2021 11:15:04 -0400 Received: from mail.nic.cz ([217.31.204.67]:46284 "EHLO mail.nic.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350114AbhDNPPD (ORCPT ); Wed, 14 Apr 2021 11:15:03 -0400 Received: from thinkpad (unknown [IPv6:2a0e:b107:ae1:0:3e97:eff:fe61:c680]) by mail.nic.cz (Postfix) with ESMTPSA id C5E55140AF8; Wed, 14 Apr 2021 17:14:40 +0200 (CEST) Date: Wed, 14 Apr 2021 17:14:39 +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: <20210414171439.1a2e7c1a@thinkpad> In-Reply-To: <87fszujbif.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> <20210413015450.1ae597da@thinkpad> <20210413022730.2a51c083@thinkpad> <87im4qjl87.fsf@waldekranz.com> <20210413171443.1b2b2f88@thinkpad> <87fszujbif.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 20:16:24 +0200 Tobias Waldekranz wrote: > You could imagine a different mode in which the DSA driver would receive > the bucket allocation from the bond/team driver (which in turn could > come all the way from userspace). Userspace could then implement > whatever strategy it wants to maximize utilization, though still bound > by the limitations of the hardware in terms of fields considered during > hashing of course. The problem is that even with the ability to change the bucket configuration however we want it still can happen with non-trivial probability that all (src,dst) pairs on the network will hash to one bucket. The probability of that happening is 1/(8^(n-1)) for n (src,dst) pairs. On Turris Omnia the most common configuration is that the switch ports are bridged. If the user plugs only two devices into the lan ports, one would expect that both devices could utilize 1 gbps each. In this case there is 1/8 probability that both devices would hash to the same bucket. It is quite bad if multi-CPU upload won't work for 12.5% of our customers that are using our device in this way. So if there is some reasonable solution how to implement multi-CPU via the port vlan mask, I will try to pursue this. Marek