mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
To: Andrew Lunn <andrew@lunn.ch>, Michael Dege <michael.dege@renesas.com>
Cc: "Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Richard Cochran" <richardcochran@gmail.com>,
	"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
	"Paul Barker" <paul@pbarker.dev>, "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Magnus Damm" <magnus.damm@gmail.com>,
	netdev@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	"Christophe JAILLET" <christophe.jaillet@wanadoo.fr>
Subject: Re: [PATCH net-next 09/10] net: renesas: rswitch: add simple l3 routing
Date: Fri, 7 Nov 2025 11:02:04 +0100	[thread overview]
Message-ID: <03012c3b-ae9d-4591-8ac5-8cf302b794a5@cogentembedded.com> (raw)
In-Reply-To: <06213fb1-12dc-4045-803e-d2a65c7e9fc6@lunn.ch>

>> +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

  reply	other threads:[~2025-11-07 10:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-06 12:55 [PATCH net-next 00/10] net: renesas: rswitch: R-Car S4 add HW offloading for layer 3 routing Michael Dege
2025-11-06 12:55 ` [PATCH net-next 01/10] net: renesas: rswitch: cleanup MII settings Michael Dege
2025-11-06 12:55 ` [PATCH net-next 02/10] net: renesas: rswitch: enable Phy link status pin Michael Dege
2025-11-07  1:16   ` Andrew Lunn
2025-11-07 13:37     ` Michael Dege
2025-11-06 12:55 ` [PATCH net-next 03/10] dt-bindings: net: renesas,r8a779f0-ether-switch.yaml: add optional property link-pin Michael Dege
2025-11-06 13:41   ` Geert Uytterhoeven
2025-11-06 14:19   ` Rob Herring (Arm)
2025-11-06 17:16   ` Conor Dooley
2025-11-06 12:55 ` [PATCH net-next 04/10] arm64: dts: renesas: r8a779f4-s4sk.dts add link-pin property Michael Dege
2025-11-06 12:55 ` [PATCH net-next 05/10] arm64: dts: renesas: r8a779f0-spider-ethernet.dtsi " Michael Dege
2025-11-06 12:55 ` [PATCH net-next 06/10] net: renesas: rswitch: add MAC address filtering Michael Dege
2025-11-07  1:18   ` Andrew Lunn
2025-11-06 12:55 ` [PATCH net-next 07/10] net: renesas: rswitch: fix FWPCx register names Michael Dege
2025-11-06 12:55 ` [PATCH net-next 08/10] net: renesas: rswitch: add bit access macros for forwarding engine Michael Dege
2025-11-06 12:55 ` [PATCH net-next 09/10] net: renesas: rswitch: add simple l3 routing Michael Dege
2025-11-07  2:32   ` Andrew Lunn
2025-11-07 10:02     ` Nikita Yushchenko [this message]
2025-11-07 13:29       ` Michael Dege
2025-11-07 13:46         ` Andrew Lunn
2025-11-17 10:46           ` Michael Dege
2025-11-07 13:35     ` Michael Dege
2025-11-06 12:55 ` [PATCH net-next 10/10] net: renesas: rswitch: update error handling of probe Michael Dege
2025-11-07  2:32   ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=03012c3b-ae9d-4591-8ac5-8cf302b794a5@cogentembedded.com \
    --to=nikita.yoush@cogentembedded.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=geert+renesas@glider.be \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=michael.dege@renesas.com \
    --cc=netdev@vger.kernel.org \
    --cc=niklas.soderlund@ragnatech.se \
    --cc=pabeni@redhat.com \
    --cc=paul@pbarker.dev \
    --cc=richardcochran@gmail.com \
    --cc=robh@kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®