On Mon, Mar 12, 2018 at 6:11 PM, Andrew Lunn wrote:
>> 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 pr
> 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 switc
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 it
On Fri, Mar 09, 2018 at 07:03:06PM -0800, Igor Mitsyanko wrote:
> Introduce BR_FLOOD_OFFLOAD bridge port flag that can be used by
> switchdev-capable hardware to advertize that it wants to handle all
> flooding by itself.
> In that case there is no need for a driver to set skb::offload_fwd_mark
> o
