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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 DD44DC433E0 for ; Wed, 10 Feb 2021 02:00:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9FE9564E45 for ; Wed, 10 Feb 2021 02:00:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235190AbhBJCAT (ORCPT ); Tue, 9 Feb 2021 21:00:19 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:59014 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233826AbhBJA3l (ORCPT ); Tue, 9 Feb 2021 19:29:41 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1l9dN7-005CzA-Vx; Wed, 10 Feb 2021 01:28:45 +0100 Date: Wed, 10 Feb 2021 01:28:45 +0100 From: Andrew Lunn To: Mickey Rachamim Cc: Jakub Kicinski , Vadym Kochan , Tobias Waldekranz , "David S. Miller" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Vladimir Oltean Subject: Re: [EXT] Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support Message-ID: References: <20210203165458.28717-1-vadym.kochan@plvision.eu> <20210203165458.28717-6-vadym.kochan@plvision.eu> <20210204211647.7b9a8ebf@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <87v9b249oq.fsf@waldekranz.com> <20210208130557.56b14429@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210209093500.53b55ca8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Right at the beginning - we implemented PP function into the Kernel > driver like the SDMA operation (This is the RX/TX DMA engine). > We do plan to port more and more PP functions as Kernel drivers > along the way. It will be interesting to see how well you manage to handle the 'split brain' problem. DMA packets to/from the host is pretty isolated from the rest of the driver. Look at DSA, it has completely separate drivers. But when you start having parts of the control plain in the driver poking switch registers, and parts of the control plane in the SDK poking registers, you have an interesting synchronisation problem. I guess stats would be a good place to start. Throw away the current code making an RPC into the SDK, and just directly get the values from the registers. No real synchronisation problems there. In fact, most of the ethtool get API calls should be reasonably easy to do via direct hardware access, rather than using the SDK RPC. Getting values like that should be easy to synchronise. Andrew