linux-kernel - RE: [PATCH net-next 09/10] net: renesas: rswitch: add simple l3 routing

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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <TY4PR01MB142826AEB522E9717D6B1E59B82C3A@TY4PR01MB14282.jpnprd01.prod.outlook.com>
Date: Fri, 7 Nov 2025 13:29:33 +0000
From: Michael Dege <michael.dege@...esas.com>
To: Nikita Yushchenko <nikita.yoush@...entembedded.com>, Andrew Lunn
	<andrew@...n.ch>
CC: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>, 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>, Richard Cochran <richardcochran@...il.com>,
	niklas.soderlund <niklas.soderlund@...natech.se>, Paul Barker
	<paul@...rker.dev>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
	<krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Geert Uytterhoeven
	<geert+renesas@...der.be>, magnus.damm <magnus.damm@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Christophe JAILLET
	<christophe.jaillet@...adoo.fr>
Subject: RE: [PATCH net-next 09/10] net: renesas: rswitch: add simple l3
 routing



> -----Original Message-----
> From: Nikita Yushchenko <nikita.yoush@...entembedded.com>
> Sent: Friday, November 7, 2025 11:02 AM
> To: Andrew Lunn <andrew@...n.ch>; Michael Dege <michael.dege@...esas.com>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>; 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>; Richard Cochran <richardcochran@...il.com>; niklas.soderlund
> <niklas.soderlund@...natech.se>; Paul Barker <paul@...rker.dev>; Rob Herring <robh@...nel.org>;
> Krzysztof Kozlowski <krzk+dt@...nel.org>; Conor Dooley <conor+dt@...nel.org>; Geert Uytterhoeven
> <geert+renesas@...der.be>; magnus.damm <magnus.damm@...il.com>; netdev@...r.kernel.org; linux-renesas-
> soc@...r.kernel.org; linux-kernel@...r.kernel.org; devicetree@...r.kernel.org; Christophe JAILLET
> <christophe.jaillet@...adoo.fr>
> Subject: Re: [PATCH net-next 09/10] net: renesas: rswitch: add simple l3 routing
>
> >> +static bool rmon_ipv4_dst_offload_hw_op(struct rswitch_route_monitor *rmon,
> >> +                                  struct rmon_ipv4_dst_offload *offload,
> >> +                                  u8 frame_type, bool install)
> >
> > Why all this bool functions? Especially when you have calls returning
> > error codes you are throwing away.
>
> The original idea behind that was - this is "not success" from an optional optimization step, that is
> not exposed outside. If it fails to offload - then the stream will remain handled by software.
>
>
> But, there is a more interesting question about this patchset (that actually stopped me from
> submitting
> it when it was originally developed).
>
> What do people thing about the entire approach used to detect streams to offload?
>
> The situation is:
> - hardware is capable of doing L3 routing, with some (limited) packet update capabilities - rewrite
> DST
> MAC, decrease TTL,
> - there is interest to use that, because software L3 routing even at 1Gbps consumes significant CPU
> load, and for 5Gbps will likely not keep the speed at all (we did not have hw to try),
> - but - given the capabilities of hw are incomparably weaker than capabilities of linux networking,
> which approach to take to detect streams for offloading?
>
> Second question - how exactly to get the routing decision from the kernel stack, to apply it in
> hardware? I was not able to find any existing implementations of something similar...
>
> What the patchset actually implements is - maintains it's own shadow structures for (subset of)
> routing
> information, and generate offload rules based on that. This is definitely not elegant (because the
> same
> kernel where this code runs maintains full-scale routing structures).  Also this is definitely
> breaking
> any complex cases - actually anything more complex than simple destination mask based routing.
>
> I was going to post this approach as RFC at some point, raising all these questions...  but
> unfortunately I did not have a resource to complete that :(
>
> Nikita

Hello Nikita,

Thank you for stepping in and explaining the situation.

Michael
________________________________

Renesas Electronics Europe GmbH
Registered Office: Arcadiastrasse 10
DE-40472 Duesseldorf
Commercial Registry: Duesseldorf, HRB 3708
Managing Director: Carsten Jauch
VAT-No.: DE 14978647
Tax-ID-No: 105/5839/1793

Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.