netdev - Re: [PATCH net-next 0/5] Code movement to br

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20211102172000.byrxnde5fg3p4wqg@skbuf>
Date:   Tue, 2 Nov 2021 17:20:00 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Roopa Prabhu <roopa@...dia.com>,
        Nikolay Aleksandrov <nikolay@...dia.com>,
        Jiri Pirko <jiri@...dia.com>, Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next 0/5] Code movement to br_switchdev.c

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:
> > On Tue, Nov 02, 2021 at 12:49:53PM +0100, Jiri Pirko wrote:
> > > Tue, Nov 02, 2021 at 12:11:59PM CET, vladimir.oltean@....com wrote:
> > > >On Mon, Nov 01, 2021 at 04:05:45PM +0100, Jiri Pirko wrote:
> > > >> Wed, Oct 27, 2021 at 06:21:14PM CEST, vladimir.oltean@....com wrote:
> > > >> >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.