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:	Mon, 23 Mar 2015 10:12:45 -0700
From:	roopa <roopa@...ulusnetworks.com>
To:	Guenter Roeck <linux@...ck-us.net>
CC:	John Fastabend <john.fastabend@...il.com>,
	Andrew Lunn <andrew@...n.ch>,
	David Miller <davem@...emloft.net>, sfeldma@...il.com,
	jiri@...nulli.us, ronen.arad@...el.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded
 packets

On 3/22/15, 8:33 PM, Guenter Roeck wrote:
> On 03/22/2015 08:18 PM, John Fastabend wrote:
> [ ... ]
>>
>> Sorry I probably wasn't being clear. I'm just saying we don't need to
>> have the driver tell us if the packet has been forwarded. All we have
>> to do in software is the switch check and assume all packets sent to us
>> from the driver have already been handled by the hardware. Roopa is
>> working on this I believe.
>>
>
> Ah, ok. Yes, you are correct. Sorry, I missed that.
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.

thanks,
Roopa




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