All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: netdev@vger.kernel.org, bridge@lists.linux-foundation.org
Cc: petrm@nvidia.com, mlxsw@nvidia.com, razor@blackwall.org,
	Ido Schimmel <idosch@nvidia.com>,
	edumazet@google.com, roopa@nvidia.com, kuba@kernel.org,
	pabeni@redhat.com, davem@davemloft.net
Subject: [Bridge] [RFC PATCH net-next 1/9] bridge: Reorder neighbor suppression check when flooding
Date: Thu, 13 Apr 2023 12:58:22 +0300	[thread overview]
Message-ID: <20230413095830.2182382-2-idosch@nvidia.com> (raw)
In-Reply-To: <20230413095830.2182382-1-idosch@nvidia.com>

The bridge does not flood ARP / NS packets for which a reply was sent to
bridge ports that have neighbor suppression enabled.

Subsequent patches are going to add per-{Port, VLAN} neighbor
suppression, which is going to make it more expensive to check whether
neighbor suppression is enabled since a VLAN lookup will be required.

Therefore, instead of unnecessarily performing this lookup for every
packet, only perform it for ARP / NS packets for which a reply was sent.

Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 net/bridge/br_forward.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index 02bb620d3b8d..0fe133fa214c 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -224,8 +224,8 @@ void br_flood(struct net_bridge *br, struct sk_buff *skb,
 		/* Do not flood to ports that enable proxy ARP */
 		if (p->flags & BR_PROXYARP)
 			continue;
-		if ((p->flags & (BR_PROXYARP_WIFI | BR_NEIGH_SUPPRESS)) &&
-		    BR_INPUT_SKB_CB(skb)->proxyarp_replied)
+		if (BR_INPUT_SKB_CB(skb)->proxyarp_replied &&
+		    (p->flags & (BR_PROXYARP_WIFI | BR_NEIGH_SUPPRESS)))
 			continue;
 
 		prev = maybe_deliver(prev, p, skb, local_orig);
-- 
2.37.3


WARNING: multiple messages have this Message-ID (diff)
From: Ido Schimmel <idosch@nvidia.com>
To: netdev@vger.kernel.org, bridge@lists.linux-foundation.org
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, razor@blackwall.org, roopa@nvidia.com,
	petrm@nvidia.com, mlxsw@nvidia.com,
	Ido Schimmel <idosch@nvidia.com>
Subject: [RFC PATCH net-next 1/9] bridge: Reorder neighbor suppression check when flooding
Date: Thu, 13 Apr 2023 12:58:22 +0300	[thread overview]
Message-ID: <20230413095830.2182382-2-idosch@nvidia.com> (raw)
In-Reply-To: <20230413095830.2182382-1-idosch@nvidia.com>

The bridge does not flood ARP / NS packets for which a reply was sent to
bridge ports that have neighbor suppression enabled.

Subsequent patches are going to add per-{Port, VLAN} neighbor
suppression, which is going to make it more expensive to check whether
neighbor suppression is enabled since a VLAN lookup will be required.

Therefore, instead of unnecessarily performing this lookup for every
packet, only perform it for ARP / NS packets for which a reply was sent.

Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 net/bridge/br_forward.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index 02bb620d3b8d..0fe133fa214c 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -224,8 +224,8 @@ void br_flood(struct net_bridge *br, struct sk_buff *skb,
 		/* Do not flood to ports that enable proxy ARP */
 		if (p->flags & BR_PROXYARP)
 			continue;
-		if ((p->flags & (BR_PROXYARP_WIFI | BR_NEIGH_SUPPRESS)) &&
-		    BR_INPUT_SKB_CB(skb)->proxyarp_replied)
+		if (BR_INPUT_SKB_CB(skb)->proxyarp_replied &&
+		    (p->flags & (BR_PROXYARP_WIFI | BR_NEIGH_SUPPRESS)))
 			continue;
 
 		prev = maybe_deliver(prev, p, skb, local_orig);
-- 
2.37.3


  reply	other threads:[~2023-04-13  9:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13  9:58 [Bridge] [RFC PATCH net-next 0/9] bridge: Add per-{Port, VLAN} neighbor suppression Ido Schimmel
2023-04-13  9:58 ` Ido Schimmel
2023-04-13  9:58 ` Ido Schimmel [this message]
2023-04-13  9:58   ` [RFC PATCH net-next 1/9] bridge: Reorder neighbor suppression check when flooding Ido Schimmel
2023-04-13  9:58 ` [Bridge] [RFC PATCH net-next 2/9] bridge: Pass VLAN ID to br_flood() Ido Schimmel
2023-04-13  9:58   ` Ido Schimmel
2023-04-13  9:58 ` [Bridge] [RFC PATCH net-next 3/9] bridge: Add internal flags for per-{Port, VLAN} neighbor suppression Ido Schimmel
2023-04-13  9:58   ` Ido Schimmel
2023-04-13  9:58 ` [Bridge] [RFC PATCH net-next 4/9] bridge: Take per-{Port, VLAN} neighbor suppression into account Ido Schimmel
2023-04-13  9:58   ` Ido Schimmel
2023-04-13  9:58 ` [Bridge] [RFC PATCH net-next 5/9] bridge: Encapsulate data path neighbor suppression logic Ido Schimmel
2023-04-13  9:58   ` Ido Schimmel
2023-04-13  9:58 ` [Bridge] [RFC PATCH net-next 6/9] bridge: Add per-{Port, VLAN} neighbor suppression data path support Ido Schimmel
2023-04-13  9:58   ` Ido Schimmel
2023-04-13  9:58 ` [Bridge] [RFC PATCH net-next 7/9] bridge: vlan: Allow setting VLAN neighbor suppression state Ido Schimmel
2023-04-13  9:58   ` Ido Schimmel
2023-04-13  9:58 ` [Bridge] [RFC PATCH net-next 8/9] bridge: Allow setting per-{Port, VLAN} " Ido Schimmel
2023-04-13  9:58   ` Ido Schimmel
2023-04-13  9:58 ` [Bridge] [RFC PATCH net-next 9/9] selftests: net: Add bridge neighbor suppression test Ido Schimmel
2023-04-13  9:58   ` Ido Schimmel
2023-04-19 12:30 ` [Bridge] [RFC PATCH net-next 0/9] bridge: Add per-{Port, VLAN} neighbor suppression Nikolay Aleksandrov
2023-04-19 12:30   ` Nikolay Aleksandrov
2023-04-19 13:59   ` [Bridge] " Ido Schimmel
2023-04-19 13:59     ` Ido Schimmel
2023-04-19 14:51     ` [Bridge] " Vladimir Oltean
2023-04-19 14:51       ` Vladimir Oltean
2023-04-19 15:04       ` [Bridge] " Ido Schimmel
2023-04-19 15:04         ` Ido Schimmel

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=20230413095830.2182382-2-idosch@nvidia.com \
    --to=idosch@nvidia.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    --cc=razor@blackwall.org \
    --cc=roopa@nvidia.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.