netdev - Re: [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded packets

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]

Date:	Tue, 24 Mar 2015 06:13:39 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Scott Feldman <sfeldma@...il.com>,
	roopa <roopa@...ulusnetworks.com>
CC:	John Fastabend <john.fastabend@...il.com>,
	Andrew Lunn <andrew@...n.ch>,
	David Miller <davem@...emloft.net>,
	Jiří Pírko <jiri@...nulli.us>,
	"Arad, Ronen" <ronen.arad@...el.com>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded
 packets

On 03/23/2015 10:59 PM, Scott Feldman wrote:
> On Mon, Mar 23, 2015 at 10:12 AM, roopa <roopa@...ulusnetworks.com> wrote:
>> On 3/22/15, 8:33 PM, Guenter Roeck wrote:
>>>
[ ... ]
>>
>> yep, so my first RFC listed three ways to do this,
>> 1) flag on the bridge port
>> 2) check if the port being forwarded to is a switch port, using
>>              - the offload flag
>>              - the parent id (as john fastabend pointed out)
>> 3) A per packet flag which switch driver sets indicating that the packet is
>> hw forwarded.
>>      This is because we have run into cases where we want to move to software
>> forwarding
>>      of certain packets like igmp reports.  (I will get some more details on
>> the particular igmp problem).
>>      In such case, hardware punts the igmp packet to cpu and cpu will do the
>> forwarding.
>>      I think we may hit more cases like this in the future.
>>
>> my RFC v1 was based on 1). RFC v2 was based on 3) above.
>>
>> But, for now, agree that we can just support the more common case using 2).
>> And, we can move to 3) in the future if needed.
>
> Roopa, I think it may be possible to do this without any changes to
> the bridge code or switchdev code by dropping duplicate pkts in the
> swdev driver itself.  The skb is marked with skb_iif set to ifindex of
> ingress port, so when the driver goes to egress a pkt on the port, if
> the skb_iif is one of the other device ports, we can assume the device
> did the fwd already so we can drop the duplicate pkt.  Below is the
> change to rocker.  The driver can get as fancy as it wants in its test
> to drop or not.  This solution works for mixed offload and
> non-offloaded ports in a bridge, or ports from different offload
> devices in the same bridge.
>
> Yes, the bridge is spending overhead to clone pkts to flood to its
> ports.  IGMP snooping mitigates this for mcast.  BR_FLOOD can be
> turned off on the bridge ports to mitigate this for unknown unicast
> floods.  So what's left is bcasts.
>
You would still want the soft bridge code to flood from non-switch ports
to switch ports and vice versa, as well as across multiple switches.
So I am not entirely sure I understand how turning off BR_FLOOD would help.

Thanks,
Guenter

--
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