netdev - RE: [RFC PATCH net-next] bridge: ability to disable forwarding on a port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <E4CD12F19ABA0C4D8729E087A761DC3505DF57DB@ORSMSX101.amr.corp.intel.com>
Date:	Sat, 17 Jan 2015 21:14:10 +0000
From:	"Arad, Ronen" <ronen.arad@...el.com>
To:	"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"jhs@...atatu.com" <jhs@...atatu.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"sfeldma@...il.com" <sfeldma@...il.com>,
	"jiri@...nulli.us" <jiri@...nulli.us>,
	"tgraf@...g.ch" <tgraf@...g.ch>,
	"john.fastabend@...il.com" <john.fastabend@...il.com>,
	"vyasevic@...hat.com" <vyasevic@...hat.com>
CC:	"wkok@...ulusnetworks.com" <wkok@...ulusnetworks.com>,
	"gospo@...ulusnetworks.com" <gospo@...ulusnetworks.com>
Subject: RE: [RFC PATCH net-next] bridge: ability to disable forwarding on a
 port



>-----Original Message-----
>From: roopa@...ulusnetworks.com [mailto:roopa@...ulusnetworks.com]
>Sent: Friday, January 16, 2015 11:33 PM
>To: stephen@...workplumber.org; davem@...emloft.net; jhs@...atatu.com;
>sfeldma@...il.com; jiri@...nulli.us; Arad, Ronen; tgraf@...g.ch;
>john.fastabend@...il.com; vyasevic@...hat.com
>Cc: netdev@...r.kernel.org; wkok@...ulusnetworks.com;
>gospo@...ulusnetworks.com
>Subject: [RFC PATCH net-next] bridge: ability to disable forwarding on a port
>
>From: Roopa Prabhu <roopa@...ulusnetworks.com>
>
>On a Linux bridge with bridge forwarding offloaded to a switch ASIC,
>there is a need to not re-forward the frames that come up to the
>kernel in software.
>
>Typically these are broadcast or multicast packets forwarded by the
>hardware to multiple destination ports including sending a copy of
>the packet to the kernel (e.g. an arp broadcast).
>The bridge driver will try to forward the packet again, resulting in
>two copies of the same packet.
>
>These packets can also come up to the kernel for logging when they hit
>a LOG acl in hardware.
>
>This patch makes forwarding a flag on the port similar to
>learn and flood and drops the packet just before forwarding.
>(The forwarding disable on a bridge is tested to work on our boxes.
>The bridge port flag addition is only compile tested.
>This will need to be further refined to cover cases where a non-switch port
>is bridged to a switch port etc. We will submit more patches to cover
>all cases if we agree on this approach).
>
>Other ways to solve the same problem could be to:
>- use the offload feature flag on these switch ports to avoid the
>re-forward:
>https://www.marc.info/?l=linux-netdev&m=141820235010603&w=2
>
>- Or the switch driver can mark or set a flag in the skb, which the bridge
>driver can use to avoid a re-forward.
>

The proposed patch does not go along with the offload feature flag.
The premise of the offload feature flag is that offloading is driven by the 
switch port driver without user intervention. This patch requires different
setting for BR_FLOOD in the software bridge port and the switch port driver.
The alternatives suggested (offload flag or skb flag) are better.

The proposed patch avoids re-forward but not without cost. For example in the
case of unicast flood with local destination, the skb is cloned for each port
before the forward avoidance in __br_forward. Is it acceptable overhead?
  
[...]

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html