All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: ivecera@redhat.com, jiri@resnulli.us,
	nikolay@cumulusnetworks.com, netdev@vger.kernel.org,
	roopa@cumulusnetworks.com, bridge@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com,
	anirudh.venkataramanan@intel.com, jeffrey.t.kirsher@intel.com,
	olteanv@gmail.com, davem@davemloft.net
Subject: Re: [Bridge] [RFC net-next v3 09/10] net: bridge: mrp: Integrate MRP into the bridge
Date: Sat, 25 Jan 2020 17:16:15 +0100	[thread overview]
Message-ID: <20200125161615.GD18311@lunn.ch> (raw)
In-Reply-To: <20200124161828.12206-10-horatiu.vultur@microchip.com>

>  br_netif_receive_skb(struct net *net, struct sock *sk, struct sk_buff *skb)
> @@ -338,6 +341,17 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
>  			return RX_HANDLER_CONSUMED;
>  		}
>  	}
> +#ifdef CONFIG_BRIDGE_MRP
> +	/* If there is no MRP instance do normal forwarding */
> +	if (!p->mrp_aware)
> +		goto forward;
> +
> +	if (skb->protocol == htons(ETH_P_MRP))
> +		return RX_HANDLER_PASS;

What MAC address is used for these MRP frames? It would make sense to
use a L2 link local destination address, since i assume they are not
supposed to be forwarded by the bridge. If so, you could extend the
if (unlikely(is_link_local_ether_addr(dest))) condition.

> +
> +	if (p->state == BR_STATE_BLOCKING)
> +		goto drop;
> +#endif

Is this needed? The next block of code is a switch statement on
p->state. The default case, which BR_STATE_BLOCKING should hit, is
drop.

This function is on the hot path. So we should try to optimize it as
much as possible.

     Andrew

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
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
Date: Sat, 25 Jan 2020 17:16:15 +0100	[thread overview]
Message-ID: <20200125161615.GD18311@lunn.ch> (raw)
In-Reply-To: <20200124161828.12206-10-horatiu.vultur@microchip.com>

>  br_netif_receive_skb(struct net *net, struct sock *sk, struct sk_buff *skb)
> @@ -338,6 +341,17 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
>  			return RX_HANDLER_CONSUMED;
>  		}
>  	}
> +#ifdef CONFIG_BRIDGE_MRP
> +	/* If there is no MRP instance do normal forwarding */
> +	if (!p->mrp_aware)
> +		goto forward;
> +
> +	if (skb->protocol == htons(ETH_P_MRP))
> +		return RX_HANDLER_PASS;

What MAC address is used for these MRP frames? It would make sense to
use a L2 link local destination address, since i assume they are not
supposed to be forwarded by the bridge. If so, you could extend the
if (unlikely(is_link_local_ether_addr(dest))) condition.

> +
> +	if (p->state == BR_STATE_BLOCKING)
> +		goto drop;
> +#endif

Is this needed? The next block of code is a switch statement on
p->state. The default case, which BR_STATE_BLOCKING should hit, is
drop.

This function is on the hot path. So we should try to optimize it as
much as possible.

     Andrew

  parent reply	other threads:[~2020-01-25 16:16 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24 16:18 [Bridge] [RFC net-next v3 00/10] net: bridge: mrp: Add support for Media Redundancy Protocol (MRP) Horatiu Vultur
2020-01-24 16:18 ` Horatiu Vultur
2020-01-24 16:18 ` [Bridge] [RFC net-next v3 01/10] net: bridge: mrp: Expose mrp attributes Horatiu Vultur
2020-01-24 16:18   ` Horatiu Vultur
2020-01-24 16:18 ` [Bridge] [RFC net-next v3 02/10] net: bridge: mrp: Expose function br_mrp_port_open Horatiu Vultur
2020-01-24 16:18   ` Horatiu Vultur
2020-01-24 17:37   ` [Bridge] " Andrew Lunn
2020-01-24 17:37     ` Andrew Lunn
2020-01-25 11:29     ` [Bridge] " Horatiu Vultur
2020-01-25 11:29       ` Horatiu Vultur
2020-01-24 16:18 ` [Bridge] [RFC net-next v3 03/10] net: bridge: mrp: Add MRP interface used by netlink Horatiu Vultur
2020-01-24 16:18   ` Horatiu Vultur
2020-01-24 17:43   ` [Bridge] " Andrew Lunn
2020-01-24 17:43     ` Andrew Lunn
2020-01-25 11:37     ` [Bridge] " Horatiu Vultur
2020-01-25 11:37       ` Horatiu Vultur
2020-01-25 15:20       ` [Bridge] " Andrew Lunn
2020-01-25 15:20         ` Andrew Lunn
2020-01-25 19:16         ` [Bridge] " Allan W. Nielsen
2020-01-25 19:16           ` Allan W. Nielsen
2020-01-26 13:28           ` [Bridge] " Horatiu Vultur
2020-01-26 13:28             ` Horatiu Vultur
2020-01-26 15:39             ` [Bridge] " Andrew Lunn
2020-01-26 15:39               ` Andrew Lunn
2020-02-20  9:08             ` [Bridge] " Nikolay Aleksandrov
2020-02-20  9:08               ` Nikolay Aleksandrov
2020-02-20 13:00               ` [Bridge] " Allan W. Nielsen
2020-02-20 13:00                 ` Allan W. Nielsen
2020-01-24 16:18 ` [Bridge] [RFC net-next v3 04/10] net: bridge: mrp: Add generic netlink interface to configure MRP Horatiu Vultur
2020-01-24 16:18   ` Horatiu Vultur
2020-01-25 15:34   ` [Bridge] " Andrew Lunn
2020-01-25 15:34     ` Andrew Lunn
2020-01-25 19:28     ` [Bridge] " Allan W. Nielsen
2020-01-25 19:28       ` Allan W. Nielsen
2020-01-26 13:39       ` [Bridge] " Horatiu Vultur
2020-01-26 13:39         ` Horatiu Vultur
2020-01-27 15:39     ` [Bridge] " Jürgen Lambrecht
2020-01-24 16:18 ` [Bridge] [RFC net-next v3 05/10] net: bridge: mrp: Update MRP interface to add switchdev support Horatiu Vultur
2020-01-24 16:18   ` Horatiu Vultur
2020-01-24 16:18 ` [Bridge] [RFC net-next v3 06/10] net: bridge: mrp: switchdev: Extend switchdev API to offload MRP Horatiu Vultur
2020-01-24 16:18   ` Horatiu Vultur
2020-01-25 16:35   ` [Bridge] " Andrew Lunn
2020-01-25 16:35     ` Andrew Lunn
2020-01-26 13:22     ` [Bridge] " Horatiu Vultur
2020-01-26 13:22       ` Horatiu Vultur
2020-01-26 15:59       ` [Bridge] " Andrew Lunn
2020-01-26 15:59         ` Andrew Lunn
2020-01-27 11:04         ` [Bridge] " Allan W. Nielsen
2020-01-27 11:04           ` Allan W. Nielsen
2020-01-27 14:26           ` [Bridge] " Jürgen Lambrecht
2020-01-27 15:06             ` Andrew Lunn
2020-01-27 15:06               ` Andrew Lunn
2020-01-27 14:41           ` [Bridge] " Jürgen Lambrecht
2020-01-27 14:41             ` Jürgen Lambrecht
2020-01-28  9:50           ` Jürgen Lambrecht
2020-01-27 11:29         ` [Bridge] " Jürgen Lambrecht
2020-01-27 11:29           ` Jürgen Lambrecht
2020-01-27 12:27           ` [Bridge] " Allan W. Nielsen
2020-01-27 12:27             ` Allan W. Nielsen
2020-01-27 14:39             ` [Bridge] " Jürgen Lambrecht
2020-01-27 14:39               ` Jürgen Lambrecht
2020-01-28  9:58               ` [Bridge] " Allan W. Nielsen
2020-01-28  9:58                 ` Allan W. Nielsen
2020-01-24 16:18 ` [Bridge] [RFC net-next v3 07/10] net: bridge: mrp: switchdev: Implement MRP API for switchdev Horatiu Vultur
2020-01-24 16:18   ` Horatiu Vultur
2020-01-24 16:18 ` [Bridge] [RFC net-next v3 08/10] net: bridge: mrp: Connect MRP api with the switchev API Horatiu Vultur
2020-01-24 16:18   ` Horatiu Vultur
2020-01-24 16:18 ` [Bridge] [RFC net-next v3 09/10] net: bridge: mrp: Integrate MRP into the bridge Horatiu Vultur
2020-01-24 16:18   ` Horatiu Vultur
2020-01-25 15:42   ` [Bridge] " Andrew Lunn
2020-01-25 15:42     ` Andrew Lunn
2020-01-26 12:49     ` [Bridge] " Horatiu Vultur
2020-01-26 12:49       ` Horatiu Vultur
2020-01-25 16:16   ` Andrew Lunn [this message]
2020-01-25 16:16     ` Andrew Lunn
2020-01-26 13:01     ` [Bridge] " Horatiu Vultur
2020-01-26 13:01       ` Horatiu Vultur
2020-01-26 17:12       ` [Bridge] " Andrew Lunn
2020-01-26 17:12         ` Andrew Lunn
2020-01-27 10:57         ` [Bridge] " Allan W. Nielsen
2020-01-27 10:57           ` Allan W. Nielsen
2020-01-27 13:02           ` [Bridge] " Horatiu Vultur
2020-01-27 13:02             ` Horatiu Vultur
2020-01-27 13:40           ` [Bridge] " Andrew Lunn
2020-01-27 13:40             ` Andrew Lunn
2020-01-27 15:33             ` [Bridge] " Jürgen Lambrecht
2020-01-28  9:56             ` Jürgen Lambrecht
2020-01-28  9:56               ` Jürgen Lambrecht
2020-01-28 10:17             ` [Bridge] " Allan W. Nielsen
2020-01-28 10:17               ` Allan W. Nielsen
2020-01-24 16:18 ` [Bridge] [RFC net-next v3 10/10] net: bridge: mrp: Update Kconfig and Makefile Horatiu Vultur
2020-01-24 16:18   ` Horatiu Vultur
2020-01-24 20:34 ` [Bridge] [RFC net-next v3 00/10] net: bridge: mrp: Add support for Media Redundancy Protocol (MRP) Allan W. Nielsen
2020-01-24 20:34   ` Allan W. Nielsen
2020-01-24 21:05   ` [Bridge] " Vinicius Costa Gomes
2020-01-24 21:05     ` Vinicius Costa Gomes
2020-01-25  9:44     ` [Bridge] " Allan W. Nielsen
2020-01-25  9:44       ` Allan W. Nielsen
2020-01-25 16:23       ` [Bridge] " Andrew Lunn
2020-01-25 16:23         ` Andrew Lunn
2020-01-25 19:12         ` [Bridge] " Allan W. Nielsen
2020-01-25 19:12           ` Allan W. Nielsen
2020-01-25 21:18       ` [Bridge] " Vinicius Costa Gomes
2020-01-25 21:18         ` Vinicius Costa Gomes
2020-01-28 10:35         ` [Bridge] " Jürgen Lambrecht
2020-01-28 10:35           ` Jürgen Lambrecht
2020-02-18 12:18 ` [Bridge] " Allan W. Nielsen
2020-02-18 12:18   ` Allan W. Nielsen
2020-02-18 16:55   ` [Bridge] " Jakub Kicinski
2020-02-18 16:55     ` Jakub Kicinski
2020-02-20 10:48   ` [Bridge] " Nikolay Aleksandrov
2020-02-20 10:48     ` Nikolay Aleksandrov
2020-02-20 12:58     ` [Bridge] " Allan W. Nielsen
2020-02-20 12:58       ` Allan W. Nielsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200125161615.GD18311@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=anirudh.venkataramanan@intel.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=horatiu.vultur@microchip.com \
    --cc=ivecera@redhat.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jiri@resnulli.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@cumulusnetworks.com \
    --cc=olteanv@gmail.com \
    --cc=roopa@cumulusnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.