[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <22c691fc-c935-02b8-a370-96d9393b1cac@gmail.com>
Date: Thu, 7 May 2020 19:38:38 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Vladimir Oltean <olteanv@...il.com>, andrew@...n.ch,
vivien.didelot@...il.com, davem@...emloft.net
Cc: jiri@...nulli.us, idosch@...sch.org, kuba@...nel.org,
netdev@...r.kernel.org, nikolay@...ulusnetworks.com,
roopa@...ulusnetworks.com, mingkai.hu@....com
Subject: Re: [PATCH v3 net-next 1/4] net: bridge: allow enslaving some DSA
master network devices
On 5/3/2020 3:12 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@....com>
>
> Commit 8db0a2ee2c63 ("net: bridge: reject DSA-enabled master netdevices
> as bridge members") added a special check in br_if.c in order to check
> for a DSA master network device with a tagging protocol configured. This
> was done because back then, such devices, once enslaved in a bridge
> would become inoperative and would not pass DSA tagged traffic anymore
> due to br_handle_frame returning RX_HANDLER_CONSUMED.
>
> But right now we have valid use cases which do require bridging of DSA
> masters. One such example is when the DSA master ports are DSA switch
> ports themselves (in a disjoint tree setup). This should be completely
> equivalent, functionally speaking, from having multiple DSA switches
> hanging off of the ports of a switchdev driver. So we should allow the
> enslaving of DSA tagged master network devices.
>
> Instead of the regular br_handle_frame(), install a new function
> br_handle_frame_dummy() on these DSA masters, which returns
> RX_HANDLER_PASS in order to call into the DSA specific tagging protocol
> handlers, and lift the restriction from br_add_if.
>
> Suggested-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
> Suggested-by: Florian Fainelli <f.fainelli@...il.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> Acked-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
Tested-by: Florian Fainelli <f.fainelli@...il.com>
--
Florian
Powered by blists - more mailing lists