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=-6.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 5A188C35243 for ; Sat, 25 Jan 2020 15:42:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2FE1F20704 for ; Sat, 25 Jan 2020 15:42:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="1Oo4aMLV" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726448AbgAYPmx (ORCPT ); Sat, 25 Jan 2020 10:42:53 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:54112 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726030AbgAYPmx (ORCPT ); Sat, 25 Jan 2020 10:42:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: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=GIFd6ldOKuKN0YVghH/yGsAo5WnGw/L9zQieq8ttDrM=; b=1Oo4aMLVL4WOPNGNDBrnGbMuoK tOgjZF5dIlA65CSCX1fIDj2OjTpaTZpUJHzukaHXhhvMO+ktwOLkSk3iXzrRoQZCyPIsJ4xv7HtuP OCkPowh7h34IKzLSZlUaaKRdRNyZvFZgvC7XRXavUEa6LIfwkqBMteDgU8gam3ZkkcQM=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1ivNaC-00070X-Hn; Sat, 25 Jan 2020 16:42:48 +0100 Date: Sat, 25 Jan 2020 16:42:48 +0100 From: Andrew Lunn To: Horatiu Vultur Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bridge@lists.linux-foundation.org, jiri@resnulli.us, ivecera@redhat.com, davem@davemloft.net, roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com, anirudh.venkataramanan@intel.com, olteanv@gmail.com, jeffrey.t.kirsher@intel.com, UNGLinuxDriver@microchip.com Subject: Re: [RFC net-next v3 09/10] net: bridge: mrp: Integrate MRP into the bridge Message-ID: <20200125154248.GC18311@lunn.ch> References: <20200124161828.12206-1-horatiu.vultur@microchip.com> <20200124161828.12206-10-horatiu.vultur@microchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200124161828.12206-10-horatiu.vultur@microchip.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jan 24, 2020 at 05:18:27PM +0100, Horatiu Vultur wrote: > To integrate MRP into the bridge, the bridge needs to do the following: > - initialized and destroy the generic netlink used by MRP > - detect if the MRP frame was received on a port that is part of a MRP ring. In > case it was not, then forward the frame as usual, otherwise redirect the frame > to the upper layer. > > Signed-off-by: Horatiu Vultur > --- > net/bridge/br.c | 11 +++++++++++ > net/bridge/br_device.c | 3 +++ > net/bridge/br_if.c | 6 ++++++ > net/bridge/br_input.c | 14 ++++++++++++++ > net/bridge/br_private.h | 14 ++++++++++++++ > 5 files changed, 48 insertions(+) > > diff --git a/net/bridge/br.c b/net/bridge/br.c > index b6fe30e3768f..d5e556eed4ba 100644 > --- a/net/bridge/br.c > +++ b/net/bridge/br.c > @@ -344,6 +344,12 @@ static int __init br_init(void) > if (err) > goto err_out5; > > +#ifdef CONFIG_BRIDGE_MRP > + err = br_mrp_netlink_init(); > + if (err) > + goto err_out6; > +#endif Please try to avoid #ifdef's like this in C code. Add a stub function to br_private_mrp.h. If you really cannot avoid #ifdef, please use #if IS_ENABLED(CONFIG_BRIDGE_MRP). That expands to if (0) { } So the compiler will compile it and then optimize it out. That gives us added benefit of build testing, we don't suddenly find the code no longer compiles when we enable the option. > --- a/net/bridge/br_input.c > +++ b/net/bridge/br_input.c > @@ -21,6 +21,9 @@ > #include > #include "br_private.h" > #include "br_private_tunnel.h" > +#ifdef CONFIG_BRIDGE_MRP > +#include "br_private_mrp.h" > +#endif It should always be safe to include a header file. Andrew