mbox series

[net-next,0/3] octeontx2-af: add support for KPU profile customization

Message ID 20200921175442.16789-1-skardach@marvell.com
Headers show
Series octeontx2-af: add support for KPU profile customization | expand

Message

Stanislaw Kardach Sept. 21, 2020, 5:54 p.m. UTC
Marvell octeontx2 NPC device contains a configurable Kanguroo Parser Unit
(KPU) and CAM match key data extraction (MKEX). The octeontx2-af driver
configures them both to parse a list of standard protocol headers which
are used by netdev driver and other potential applications (i.e.
userspace through VFIO).
The problem arises when users have some custom protocol headers which
they'd like to use in CAM flow matching. If such protocols are publicly
known, they can be added to the built-in KPU configuration (called
"profile" - in npc_profile.h). If not, then there's more benefit in
keeping such changes local to the user.
For that case a mechanism which would allow users to produce a KPU
profile and load it along with octeontx2-af driver is needed. At the same
time such customization has to take care not to break the netdev driver
operation or other applications (that is be discoverable).

Therefore introduce a mechanism for a limited customization of the
built-in KPU profile via a firmware file (layout and contents described
by struct npc_kpu_profile_fwdata). It allows user modification of only a
limited number of top priority KPU entries, while others are configured
from the built-in KPU profile. Additionally by convention users should
only use NPC_LT_Lx_CUSTOMx LTYPE entries in their profiles to change the
meaning of built-in LTYPEs. This way the baseline protocol support is
always available and the impact of potential user errors is minimized.
As MKEX also needs to be modified to take into account any user
protocols, the KPU profile firmware binary contains also that. Netdev
driver and applications have a way to discover applied MKEX settings by
querying RVU AF device via NPC_GET_KEX_CFG MBOX message.
Finally some users might need to modify hardware packet data alignment
behavior and profile contains settings for that too.

First patch ensures that CUSTOMx LTYPEs are not aliased with meaningful
LTYPEs where possible.

Second patch gathers all KPU profile related data into a single struct
and creates an adapter structure which provides an interface to the KPU
profile for the octeontx2-af driver.

Third patch adds logic for loading the KPU profile through kernel
firmware APIs, filling in the customizable entries in the adapter
structure and programming the MKEX from KPU profile.

Changes from v1:
* Remove unnecessary __packed attributes. All structures in profile are
  naturally aligned and only struct npc_kpu_profile_fwdata is padded
  1B at the end, which is expected.
* Make npc_lt_defaults and npc_mkex_default const as they are read-only.
* Save custom KPU entries in separate struct npc_kpu_profile so that the
  default profile can remain read-only and there's no need to allocate
  and memcpy 25kB of default profile when customizations are present.
  The drawbacks are weaker profile abstraction and slightly more
  complicated programming steps.
  This is a result of:
  4a681bf3456f octeontx2-af: Constify npc_kpu_profile_{action,cam}
* Describe in last commit the reason for using a module parameter
  instead of an arbitrary firmware name.

Stanislaw Kardach (3):
  octeontx2-af: fix LD CUSTOM LTYPE aliasing
  octeontx2-af: prepare for custom KPU profiles
  octeontx2-af: add support for custom KPU entries

 .../net/ethernet/marvell/octeontx2/af/npc.h   |  76 +++-
 .../marvell/octeontx2/af/npc_profile.h        | 244 +++++++++++-
 .../net/ethernet/marvell/octeontx2/af/rvu.c   |   6 +
 .../net/ethernet/marvell/octeontx2/af/rvu.h   |  22 ++
 .../ethernet/marvell/octeontx2/af/rvu_nix.c   |  36 +-
 .../ethernet/marvell/octeontx2/af/rvu_npc.c   | 368 +++++++++++-------
 6 files changed, 587 insertions(+), 165 deletions(-)

Comments

David Miller Sept. 23, 2020, 12:43 a.m. UTC | #1
Please create a proper abstraction for uploading configuration information
from a file into a device.

Otherwise every driver will have their own custom weird stuff, unique
module parameter names (module parameters are absolutely rejected for
networking drivers for this reason), etc.  Therefore the user experience
will be awful.

This is non-negotiable.  We are long overdue for such a facility, and
if I were to allow a workaround like this for you, I have to allow it
for everyone else too.

Thank you.