linux-kernel - Re: [PATCH net-next] dsa: Make offloading optional on per port basis

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: <CAA8ajJn63xVmU7vd8UWT3eYtsMpVmd_njeGZRVs2DFE9MK0Eww@mail.gmail.com>
Date: Tue, 10 Dec 2024 22:31:48 -0800
From: Andrew Strohman <andrew@...rewstrohman.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Jiri Pirko <jiri@...nulli.us>, Andrew Lunn <andrew+netdev@...n.ch>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] dsa: Make offloading optional on per port basis

Hi Vladimir,

Thanks for the review. I've responded back to Jiri,
about making this more generic. I'm happy
to make this more generic, but I'd appreciate
some guidance on the best way forward.

So, if you have a suggestion about how to store
the configuration that signals that the port should
not be offloaded, I'd love to hear it.

As I described in my response to Jiri, it looks like
adding the next netdev feature will be painful.
Do you thinking adding a new netdev feature
is the best way forward here?


Thanks,

Andy





On Mon, Dec 2, 2024 at 1:45 AM Vladimir Oltean <olteanv@...il.com> wrote:
>
> On Mon, Dec 02, 2024 at 10:27:25AM +0100, Jiri Pirko wrote:
> > Why is this DSA specific? Plus, you say you want to disable offloading
> > in general (DSA_FLAG_OFFLOADING_DISABLED), but you check the flag only
> > when joining bridge. I mean, shouldn't this be rather something exposed
> > by some common UAPI?
>
> I agree with this. The proposed functionality isn't DSA specific, and
> thus, the UAPI to configure it shouldn't be made so.
>
> > Btw, isn't NETIF_F_HW_L2FW_DOFFLOAD what you are looking for?
>
> Is it? macvlan uses NETIF_F_HW_L2FW_DOFFLOAD to detect presence of
> netdev_ops->ndo_dfwd_add_station(). Having to even consider macvlan
> offload and its implications just because somebody decided to monopolize
> the "l2-fwd-offload" name seems at least bizarre in my opinion.