Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp646144ybv; Thu, 20 Feb 2020 04:59:23 -0800 (PST) X-Google-Smtp-Source: APXvYqw2Nykpho7hUhl9SD38iXNK5ezf/RbQxM08a4wvry+Mb0vml/bZFyWAv7NnqrBXd/l9f9tt X-Received: by 2002:aca:ad47:: with SMTP id w68mr1794671oie.63.1582203563523; Thu, 20 Feb 2020 04:59:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582203563; cv=none; d=google.com; s=arc-20160816; b=SfUFRL8cCc89ewN5KQw5wu+MnLbQEm2v5I34wTfg2q8eYrJMt2NwSDRnSYJHyVB0lV rUKvxYCpN4ImhEGwGQDzQS7/pag1bNi1nHwQPmo5bJrIsI+KZiqk/bP9raZOFKXFOpFS TW/1s9e/0yrqafJkD4d5aEX1ciPEs5uq1MGTADRX3KrEoHrpXm/WmVPb/ri5cP4uCpGW QyWZ8R1l0zQcbgPA+3FE1PyUC+W/TQiKBOoikNekjBYn2lr3CiRFuxG0c9a7g23nNo++ s63fPEXo7vD18TOD43PFkH8anj2XHDqFyIeCPou6yqABRYc5+v+HXbSzvmWh4CS0I+aV WhOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr; bh=W8t0FwT8emNC7zyWQWYL+mbbLOaetvwOFZn72d36e0Y=; b=cLLzqISNuXAapsqXK7ch8GTXM8IjaN/5jqeUrRXbmxOGre46Upzt1KD++NWngDgmZv 1wJ2F2atotsmezGnNGLlmTyIUgLC5a+IXhjn8MpgqWMZf68Kl4Rua6WepBunb/VejMd2 jK70xwh3l+qzGfl3AXQRkI/y0zWo+TYG6naHFvKDU6COWA3CHI6s2PCYr/usm2tKyQhA 628G4x+s1ve8yVYm4l8ZgSHBcCAMlYz4OOkmhtae+azuMVyDzvPgasj6J/gZ1p7daIS0 IbH1gcFfSXlpsiMYiS1VQcdqsi4hKXbdyQ3PbV5ecJBJ9Bcc98GSLr5qPshlcQA9mLPA pJlw== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=microchip.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t24si1654130oth.319.2020.02.20.04.59.11; Thu, 20 Feb 2020 04:59:23 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728072AbgBTM6D (ORCPT + 99 others); Thu, 20 Feb 2020 07:58:03 -0500 Received: from esa5.microchip.iphmx.com ([216.71.150.166]:12341 "EHLO esa5.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726959AbgBTM6D (ORCPT ); Thu, 20 Feb 2020 07:58:03 -0500 Received-SPF: Pass (esa5.microchip.iphmx.com: domain of Allan.Nielsen@microchip.com designates 198.175.253.82 as permitted sender) identity=mailfrom; client-ip=198.175.253.82; receiver=esa5.microchip.iphmx.com; envelope-from="Allan.Nielsen@microchip.com"; x-sender="Allan.Nielsen@microchip.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 mx a:ushub1.microchip.com a:smtpout.microchip.com -exists:%{i}.spf.microchip.iphmx.com include:servers.mcsv.net include:mktomail.com include:spf.protection.outlook.com ~all" Received-SPF: None (esa5.microchip.iphmx.com: no sender authenticity information available from domain of postmaster@email.microchip.com) identity=helo; client-ip=198.175.253.82; receiver=esa5.microchip.iphmx.com; envelope-from="Allan.Nielsen@microchip.com"; x-sender="postmaster@email.microchip.com"; x-conformance=spf_only Authentication-Results: esa5.microchip.iphmx.com; spf=Pass smtp.mailfrom=Allan.Nielsen@microchip.com; spf=None smtp.helo=postmaster@email.microchip.com; dmarc=pass (p=none dis=none) d=microchip.com IronPort-SDR: DQl9fXxlcrwCXqm1XMZdzYAl4AupcDPWhlGkyTIyUTBdmL40P1e82GDoCa9p4Y3iOnECXnWDK2 2Ea+n/UoAkChLpjhxiFbLfvv0YwCsKXt5etWoFNnxqbiJ0Pj7kONAyexWtcbwhEcBe7m6q0+qn /8irrb26zOaYzFUxj3U7xbxl/PSbwPccw/f6m/EOvF6M5LvidZJIJDTX6m0RxSZ+mGaVQgLrRS faEqBnLs+Mgic7v0wFMiLn0RtnTwCseoK882Pn4l0vnqGLDlSZxIXlQoM0S8dx7S8pqvWuj03f 2sY= X-IronPort-AV: E=Sophos;i="5.70,464,1574146800"; d="scan'208";a="66147402" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa5.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 20 Feb 2020 05:58:02 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 20 Feb 2020 05:58:09 -0700 Received: from localhost (10.10.115.15) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Thu, 20 Feb 2020 05:58:01 -0700 Date: Thu, 20 Feb 2020 13:58:00 +0100 From: "Allan W. Nielsen" To: Nikolay Aleksandrov CC: Horatiu Vultur , , , , , , , , , , , , Subject: Re: [RFC net-next v3 00/10] net: bridge: mrp: Add support for Media Redundancy Protocol (MRP) Message-ID: <20200220125800.c3qyc4wxtdt6hv4b@lx-anielsen.microsemi.net> References: <20200124161828.12206-1-horatiu.vultur@microchip.com> <20200218121811.xo3o6zzrhl5p3j2s@lx-anielsen.microsemi.net> <3afba55f-f953-7aaa-8425-14777db1b27d@cumulusnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Disposition: inline In-Reply-To: <3afba55f-f953-7aaa-8425-14777db1b27d@cumulusnetworks.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Nik, On 20.02.2020 12:48, Nikolay Aleksandrov wrote: > In light of all the discussions and details that were explained, and as you've > noted above, I think more code should be put in kernel space at the very least > the performance/latency critical parts would benefit from being executed in the > kernel (kind of control/data-plane separation). It seems from the switchdev calls there's > a minimal state working set which define the behaviour and can be used to make > decisions (similar to STP) in the kernel, but the complex logic how to set them can be > executed in user-space meaning that maybe these hw-offload calls can have a simple SW > fallback logic based on their current values. I think it is worth considering if this can > be achieved before going to full in-kernel implementation of the state machine. > Since you intend to hw-offload it then putting in some SW fallback logic would be good > when the HW can't offload everything, what you suggest above also sounds good to me and > I think you'll have to extend mdb and the multicast code to do it, but IIRC you already > have code to do that based on previous discussions. Sounds good. We will continue working on defining a good control/data-plane separation and only keep the data-plane in the kernel. Also it seems that we agree that the SW fallback of the data-plane should stay in the kernel - we will do that. > As was already suggested you can put the MRP options in the bridge's options and > process them from the bridge netlink code, that should simplify your code. I'm okay with this. The main argument I see for creating a seperate MRP netlink interface instead of extending the bridge, is that MRP is properly not the last bridge protocol we will want to work on. To complete the MRP-2018 implementation, we will also need some CFM support (defined in 802.1Qag or the latest version of 802.1Q). And furhter out we will properly want to implement the full CFM protocol. DLR may also be relevant at some point, and there may be other. My main point is, that at some point we will properly want to do seperate NETLINK interfaces for this. Not sure if that is now or later. > You could also make the port's "mrp_aware" bool into an internal port > flag (use net_bridge_port's flags field) so it can be quickly tested > and in a hot cache line. Good point, we will do that. /Allan