Re: [Bridge] [RFC PATCH net-next 3/5] bridge: allow switchdev port to handle flooding by itself

2018-03-12 Thread Andrew Lunn
> The flag was introduced to enable hardware switch capabilities of > drivers/net/wireless/quantenna/qtnfmac wifi driver. It does not have any > switchdev functionality in upstream tree at this moment, and this patchset > was intended as a preparatory change. O.K. But i suggest you add basic

Re: [Bridge] [PATCH net-next 0/5] Switchdev: flooding offload option

2018-03-12 Thread Igor Mitsyanko
On 03/10/2018 02:08 PM, Andrew Lunn wrote: Hi Igor You don't appear to be adding any user of this. Please also make one of the switchdev drivers actually use this new functionality. Andrew Hi Andrew, a first user is supposed to be drivers/net/wireless/quantenna/qtnfmac wifi driver. I

Re: [Bridge] Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw

2018-03-12 Thread Stephen Hemminger
On Mon, 12 Mar 2018 23:42:48 +0100 Rafał Miłecki wrote: > 2) Blame bridge + mcast-to-ucast + hairpin for 802.11f incompatibility > > If we agree that 802.11f support in FullMAC firmware is acceptable, then > we have to make sure Linux's bridge doesn't break it by passing

Re: [Bridge] [RFC PATCH net-next 3/5] bridge: allow switchdev port to handle flooding by itself

2018-03-12 Thread Igor Mitsyanko
On 03/10/2018 08:55 AM, Andrew Lunn wrote: Is this sufficiently granular? There are a few different use cases for flooding: There is no fdb entry in the software switch for the destination MAC address, so flood the packet out all ports of the bridge. The hardware switch might have an entry in

Re: [Bridge] [PATCH net-next 2/5] bridge: propagate BR_ flags updates through sysfs to switchdev

2018-03-12 Thread Igor Mitsyanko
On 03/10/2018 08:38 AM, Andrew Lunn wrote: + return 0; + + err = br_switchdev_set_port_flag(p, flags, mask); + if (err) + return err; You might want to consider the br_warn() in br_switchdev_set_port_flag(). Do we want to spam the kernel log? Or should

Re: [Bridge] [PATCH net-next 1/5] bridge: initialize port flags with switchdev defaults

2018-03-12 Thread Igor Mitsyanko
On 03/10/2018 08:32 AM, Stephen Hemminger wrote: Yes hardware devices may come it with different default values. But the user experience on Linux needs to be consistent. Instead, it makes more sense to me for each device driver using switchdev to program to the values that it sees in the

Re: [Bridge] [PATCH net-next 1/5] bridge: initialize port flags with switchdev defaults

2018-03-12 Thread Igor Mitsyanko
On 03/10/2018 08:30 AM, Andrew Lunn wrote: + + ret = switchdev_port_attr_get(dev, ); + if (ret) + return BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD; Hi Igor Please check if ret == -EOPNOTSUPP and only then use the defaults. A real error should be propagated,

Re: [Bridge] Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw

2018-03-12 Thread Linus Lüssing
On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote: > I've problem when using OpenWrt/LEDE on a home router with Broadcom's > FullMAC WiFi chipset. Hi Rafał, Thanks for reporting this issue! > Can you see any solution for this problem? Is that an option to stop > multicast-to-unicast