Re: [PATCH net-next 0/5] Code movement to br_switchdev.c
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: 2021-11-02 17:20:04
On Tue, Nov 02, 2021 at 06:03:33PM +0100, Andrew Lunn wrote:
On Tue, Nov 02, 2021 at 12:02:06PM +0000, Vladimir Oltean wrote:quoted
On Tue, Nov 02, 2021 at 12:49:53PM +0100, Jiri Pirko wrote:quoted
Tue, Nov 02, 2021 at 12:11:59PM CET, vladimir.oltean@nxp.com wrote:quoted
On Mon, Nov 01, 2021 at 04:05:45PM +0100, Jiri Pirko wrote:quoted
Wed, Oct 27, 2021 at 06:21:14PM CEST, vladimir.oltean@nxp.com wrote:quoted
This is one more refactoring patch set for the Linux bridge, where more logic that is specific to switchdev is moved into br_switchdev.c, which is compiled out when CONFIG_NET_SWITCHDEV is disabled.Looks good. While you are at it, don't you plan to also move switchdev.c into br_switchdev.c and eventually rename to br_offload.c ? Switchdev is about bridge offloading only anyway.You mean I should effectively make switchdev part of the bridge?Yes.Ok, have you actually seen the commit message linked below? Basically it says that there are drivers that depend on switchdev.c being this neutral third party, forwarding events on notifier chains back and forth between the bridge and the drivers. If we make switchdev.c part of the bridge, then drivers can no longer be compiled without bridge support.This is something i test every so often, building without the bridge. The simplest DSA drivers just provide a 'port multiplexor', no offload at all. You can put IP addresses on the interfaces and software route between them etc. So i would prefer this use case does not break.
I should have formulated it more carefully. That use case is not broken. What would break would be the ability to compile drivers (in this case DSA) as built-in if the bridge is a module.