linux-kernel - Re: [RFC net-next] net: devlink: add port function attr for vport ↔ eswitch metadata forwarding

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: <20250829190924.5e730888@kernel.org>
Date: Fri, 29 Aug 2025 19:09:24 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Shay Drory <shayd@...dia.com>, davem@...emloft.net, edumazet@...gle.com,
 pabeni@...hat.com, horms@...nel.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, ozsh@...dia.com, mbloch@...dia.com,
 tariqt@...dia.com, saeedm@...dia.com
Subject: Re: [RFC net-next] net: devlink: add port function attr for vport
 ↔ eswitch metadata forwarding

On Thu, 28 Aug 2025 11:03:41 +0200 Jiri Pirko wrote:
> Thu, Aug 28, 2025 at 08:52:29AM +0200, shayd@...dia.com wrote:
> >In some product architectures, the eswitch manager and the exception
> >handler run as separate user space processes. The eswitch manager uses
> >the physical uplink device, while the slow path handler uses a virtual
> >device.
> >
> >In this architectures, the eswitch manager application program the HW to
> >send the exception packets to specific vport, and on top this vport
> >virtual device, the exception application is running and handling these
> >packets.
> >
> >Currently, when packets are forwarded between the eswitch and a vport,
> >no per-packet metadata is preserved. As a result, the slow path handler
> >cannot implement features that require visibility into the packet's
> >hardware context.  
> 
> A vendor-specific slow path. Basically you provide a possibility for
> user to pass a binary blob to hw along with every TX'ed packet and
> vice versa. That looks quite odd tbh. I mean, isn't this horribly
> breaking the socket abstraction? Also, isn't this horribly breaking the
> forwarding offloading model when HW should just mimic the behaviour of
> the kernel?

I suppose will be told at some point that it's for debug.