Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3727344imu; Mon, 28 Jan 2019 09:43:12 -0800 (PST) X-Google-Smtp-Source: ALg8bN7s1DjfSFnFZD2jAbshtVusRosvjXvpizXp46OuXH2GVUIQiXitr1rDj3ubEdjvws3sykHk X-Received: by 2002:a17:902:8687:: with SMTP id g7mr22433188plo.96.1548697392370; Mon, 28 Jan 2019 09:43:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548697392; cv=none; d=google.com; s=arc-20160816; b=BkZ49ePU6GiMCYP4smX21sYR0ULDSDVpCbArizh+3RcDS9kPNhVDU82mgWNN5+7PZc JRi+Bap9hlV3DVOckvfMchSnTPGIhnTreJHYPkihDtEbu4IPDJrgHkCkwjF/GL4srmkg LnJRQUBgrrORnQX6t1hqJsbEdFg6JktXWWfYQlEZtbNXGylKwVgyW10+7P7wtBNVDCAN i0f0Vhp0bBsGHTe+1QXIlUVHXstR3FeJ5ko4PKrG0fWgowV0tLh0lEVRqFPrF/bBh8Fl BF1zRKSyT0q3k/BKpNDPv0/zcMhAhkVPPmIPL8PCEB3xTBH7djbb4kRyZagkppYM5pop FZmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=sMoY8eqIpeQH7z9JcjiW2zAEfvXKU9XUzHdDLpiU4Cc=; b=x+CGbu5pXIkyc0YDNaWggnBF8mECZlZzKslJ2//HYHYRe1lpr+HcJ1i+mGmy0FtoWV xany8aYhSUEfYpoRs2L4BJIpo/OJ2QK7FgUqL3D2d47NHvF8kUFlS6dAbeGjRAro4lKP 2o8OMI7hy6SHwBL8F1fPKG7tLFoNV87FpJxZg4jNt9QQQ0OX4ys4/4gXRXY73EtrxY04 JupZtzWWohl5Z3KdBbtGrjw4nf6kSLVUsBgC1qQrftrb1Ndf4JkSENIG9yJOiYIO5SFZ KrjXNJI1XLhjrH+QXgU3hRf02HRuTQdnzsvbXz2CgOxVy9p7aO/c2JusbMBby9zjMVb3 +iZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@lunn.ch header.s=20171124 header.b=XNt6PGm0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c11si7919233pgh.18.2019.01.28.09.42.57; Mon, 28 Jan 2019 09:43:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@lunn.ch header.s=20171124 header.b=XNt6PGm0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728752AbfA1Rmv (ORCPT + 99 others); Mon, 28 Jan 2019 12:42:51 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:58004 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728605AbfA1Rmt (ORCPT ); Mon, 28 Jan 2019 12:42:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sMoY8eqIpeQH7z9JcjiW2zAEfvXKU9XUzHdDLpiU4Cc=; b=XNt6PGm0z4bKgpElM8gs0kTsi1 Cj+t1JcKsfKirT+hr5ih4kHPbCqrhF/XUDXl+mMKhoophGArumJ0p6qXZq7IsgjpsfCjVRcp2hbp4 sD/CGL2Xg5jNiujaXMcZfkPygjEgAiltNkcm5uXrw5XOFGW1YkoP6iOJ5pu3dJuXTitY=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1goAvm-000142-0X; Mon, 28 Jan 2019 18:42:46 +0100 Date: Mon, 28 Jan 2019 18:42:46 +0100 From: Andrew Lunn To: Miquel Raynal Cc: Florian Fainelli , Vivien Didelot , "David S. Miller" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Petazzoni , Gregory Clement , Antoine Tenart , Maxime Chevallier , Nadav Haklai Subject: Re: [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules Message-ID: <20190128174246.GD28759@lunn.ch> References: <20190125095507.29334-1-miquel.raynal@bootlin.com> <20190125095507.29334-2-miquel.raynal@bootlin.com> <20190128152456.212ae5ac@xps13> <20190128144417.GG4765@lunn.ch> <20190128165749.6abf2dc4@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190128165749.6abf2dc4@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 28, 2019 at 04:57:49PM +0100, Miquel Raynal wrote: > Hi Andrew, > > Thanks for helping! > > Andrew Lunn wrote on Mon, 28 Jan 2019 15:44:17 +0100: > > > > I don't see where VLAN and bridge information are cached, can you point > > > me to the relevant locations? > > > > Miqu?l > > > > The bridge should have all that information. You need to ask it to > > enumerate the current configuration and replay it to the switch. > > > > There might be something in the Mellanox driver you can copy? But i've > > not looked, i'm just guessing. > > I am still searching but so far I did not find a mechanism reading the > configuration of the bridge out of a 'net' object. Indeed there are > multiple lists with the configuration but they are all 'mellanox' > objects, they do not belong to the core. Hi Miqu?l Look at how iproute2 works. How does the bridge command enumerate the fdb and mdb's? How does bridge vlan show work? bridge link show? See if you can use this infrastructure within the kernel. > > We also need to think about how we are going to test this. There is a > > lot of state information in a switch. So we are going to need some > > pretty good tests to show we have recreated all of it. > > My understanding of all this is rather short, until know I used what > you proposed in the v1 of this series but I am all ears if I need to > add anything to my test list. What you probably need is a generic DSA test suite, with a number of hardware devices, with different generations of mv88e6xxx devices, and ideally different sf2, kzs, etc switches. Setup a configuration and test is works correctly. Suspend, resume, and test is still works. And you probably need to go through a number of cycles of suspend/resume. And you are going to need to maintain that for a number of years, testing every release, to see what breaks as we add new features and new devices. There also needs to be some though put into what happens when the network changes while the switch is suspended. A port looses its link, a port comes up, an SFP module is ejected, and SFP module is inserted. The PTP grand master moves, etc. I hope the usual mechanisms just work, but it all needs testing. S2RAM is hard for a device like this. It is not something i personally would want to do :-( Andrew