Thread (9 messages) flat view 9 messages, 4 authors, 2021-01-25

Re: [PATCH net] net: mrp: use stp state as substitute for unimplemented mrp state

From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: 2021-01-18 21:30:30
Also in: bridge, lkml

On Mon, Jan 18, 2021 at 09:20:36PM +0100, Horatiu Vultur wrote:
The 01/18/2021 19:46, Vladimir Oltean wrote:
quoted
On Mon, Jan 18, 2021 at 07:56:18PM +0100, Horatiu Vultur wrote:
quoted
The reason was to stay away from STP, because you can't run these two
protocols at the same time. Even though in SW, we reuse port's state.
In our driver(which is not upstreamed), we currently implement
SWITCHDEV_ATTR_ID_MRP_PORT_STATE and just call the
SWITCHDEV_ATTR_ID_PORT_STP_STATE.
And isn't Rasmus's approach reasonable, in that it allows unmodified
switchdev drivers to offload MRP port states without creating
unnecessary code churn?
I am sorry but I don't see this as the correct solution. In my opinion,
I would prefer to have 3 extra lines in the driver and have a better
view of what is happening. Than having 2 calls in the driver for
different protocols.
I think the question boils down to: is a MRP-unaware driver expected to
work with the current bridge MRP code?
If it is not a problem to have STP calls when you configure the MRP,
then why not just remove SWITCHDEV_ATTR_ID_MRP_PORT_STATE?
Good question, why not?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help