netdev - Re: [PATCH net-next v2 3/3] octeontx2-af: add support for custom KPU entries

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Sep 2020 13:40:15 +0200
From:   Stanislaw Kardach <skardach@...vell.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     <davem@...emloft.net>, <sgoutham@...vell.com>,
        <netdev@...r.kernel.org>, <kda@...ihalf.com>
Subject: Re: [PATCH net-next v2 3/3] octeontx2-af: add support for custom KPU
 entries

On Mon, Sep 21, 2020 at 04:26:43PM -0700, Jakub Kicinski wrote:
> Date: Mon, 21 Sep 2020 16:26:43 -0700
> From: Jakub Kicinski <kuba@...nel.org>
> To: Stanislaw Kardach <skardach@...vell.com>
> Cc: davem@...emloft.net, sgoutham@...vell.com, netdev@...r.kernel.org,
>  kda@...ihalf.com
> Subject: Re: [PATCH net-next v2 3/3] octeontx2-af: add support for custom
>  KPU entries
> 
> On Mon, 21 Sep 2020 19:54:42 +0200 Stanislaw Kardach wrote:
> > Add ability to load a set of custom KPU entries via firmware APIs. This
> > allows for flexible support for custom protocol parsing and CAM matching.
> > 
> > The firmware file name is specified by a module parameter (kpu_profile)
> > to allow re-using the same kernel and initramfs package on nodes in
> > different parts of the network where support for different protocols is
> > required.
> > 
> > AF driver will attempt to load the profile from the firmware file and
> > verify if it can fit hardware capabilities. If not, it will revert to
> > the built-in profile.
> > 
> > Next it will read the maximum first KPU_MAX_CST_LT (2) custom entries
> > from the firmware image. Those will be later programmed at the top of
> > each KPU after the built-in profile entries have been programmed.
> > The built-in profile is amended to always contain KPU_MAX_CSR_LT first
> > no-match entries and AF driver will disable those in the KPU unless
> > custom profile is loaded.
> 
> So the driver loads the firmware contents, interprets them and programs
> the device appropriately?
> 
> Real firmware files are not usually interpreted or parsed by the driver.

Correct. I'm using the firmware file as a delivery method for a custom
configuration. There are several reasons why I chose it:

1. The parsing engine (KPU) has to be configured fully at RVU AF device
   probe, before any networking part of that or other RVU devices is
   configured. So I think this rules out devlink, ioctl or sysfs.
2. The configuration is rather extensive so cramping it into module
   parameters doesn't seem right.
3. Adding it to Device Tree in form of custom nodes makes update process
   risky to some users (as opposed to switching firmware file on a
   filesystem).
4. The request_firmware API provides a nice abstraction for the blob data
   source so I thought it might as well be used for fetching data of a
   known structure. Especially that the full layout is visible in the
   kernel and users might create those files themselves by hand.

That said all above might be because I'm unaware of a better interface to
use in such situation. If there is, I would be obliged if you could point
me in the right direction.

Stanislaw Kardach