linux-kernel - Re: [PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller

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: <20230606213542.3913d3b8@kernel.org>
Date:   Tue, 6 Jun 2023 21:35:42 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Justin Chen <justin.chen@...adcom.com>
Cc:     netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        bcm-kernel-feedback-list@...adcom.com,
        florian.fainelli@...adcom.com, davem@...emloft.net,
        edumazet@...gle.com, pabeni@...hat.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        opendmb@...il.com, andrew@...n.ch, hkallweit1@...il.com,
        linux@...linux.org.uk, richardcochran@...il.com,
        sumit.semwal@...aro.org, christian.koenig@....com,
        simon.horman@...igine.com
Subject: Re: [PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0
 Ethernet controller

On Tue, 6 Jun 2023 21:22:45 -0700 Justin Chen wrote:
> >> Through filters that can be programmed by the Host cpu or co-processor.  
> > 
> > How are the filter programmed by the host (in terms of user API)?  
> 
> You are stumbling upon my next objective here. This patch set does not 
> support this because it wasn't clear how to do it. The plan was to get 
> the base driver merged first then introduce a way to specify an offload 
> channel.

Alright.

> If you must know, I introduced a rxnfc flow_spec ring cookie to specify 
> an offload filter. Not sure if this is the right way to do it or not, 
> but figured this would be a future discussion.

We clean leave it for later indeed, but in case you're wondering -
that's unlikely to fly. My preference will be to expose the accelerator
port as a switch port, with a netdev and forward using TC flower etc.
With the netdev in place you'll have a place to report stats and all the
necessary diagnostics, which otherwise get crammed into random places.
I believe Florian asked about this in the past, I hope I'm being
consistent with my answer here :P