On Wed, Mar 24, 2021 at 02:01:14PM +0100, Tobias Waldekranz wrote:

On Wed, Mar 24, 2021 at 13:34, Vladimir Oltean [off-list ref] wrote:

quoted

On Wed, Mar 24, 2021 at 11:52:49AM +0100, Tobias Waldekranz wrote:

quoted

quoted

quoted

This is the tragedy: I know for a fact that a DSA soft parser exists,
but because of the aforementioned maze of NDAs and license agreements
we, the community, cannot have nice things.

Oh yeah? You can even create your own, if you have nerves of steel and a
thick enough skin to learn to use the "fmc" (Frame Manager Configuration
Tool) program, which is fully open source if you search for it on CAF
(and if you can actually make something out of the source code).

Yes, this is what a colleague of mine has done. Which is how I know that
one exists :)

quoted

And this PDF (hidden so well behind the maze of NDAs, that I just had to
google for it, and you don't even need to register to read it):
https://www.nxp.com/docs/en/user-guide/LSDKUG_Rev20.12.pdf
is chock full of information on what you can do with it, see chapters 8.2.5 and 8.2.6.

Right, but this is where it ends. Using the wealth of information you
have laid out so far you can use DPAA to do amazing things using open
components.

...unless you have to do something so incredibly advanced and exotic as
a masked update of a field. At this point you have two options:

1. Buy the firmware toolchain, which requires signing an NDA.
2. Buy a single-drop firmware binary for lots of $$$ without any
   possibility of getting further updates because "you should really be
   using DPAA2".

Uhm, what?
By "firmware" I assume you mean "FMan microcode"?

To my knowledge, the standard FMan microcode distributed _freely_ with
the LSDK has support for Header Manipulation, you just need to create a
Header Manipulation Command Descriptor (HMCD) and pass it to the
microcode through an O/H port. I believe that:
(a) the Header Manipulation descriptors allow you to perform raw mask
    based field updates too, not just for standard protocols

This is not the story we were told.

Wait, aren't we talking about HdrMan OPCODE 0x19 ("Replace Field in Header")?

quoted

(b) fmc already has some support for sending Header Manipulation
    descriptors to the microcode

And by "firmware toolchain" you mean the FMan microcode SDK?
https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/dpaa-fman-microcode-sdk-source-code-software-kit:DPAA-FMAN-SDK

In the description for that product it says:

  For MOST of NXP communications customers, the microcode that is freely
  accessible via the NXP LSDK or SDK for QorIQ or Layerscape processors
  will handle any communications offload task you could throw at the DPAA.

So why on earth would you need that? And does it really surprise you

Because NXP said we needed it.

quoted

that it costs money, especially considering the fact that you're going
to need heaps of support for it anyway?

No, it surprised me that we had to pay for a solution to a problem that
we were promised would be solvable using the stock firmware.

Maybe the FMan version of your particular device does not support that
HM command, or maybe you needed a slightly different behavior compared
to what HM opcode 0x19 does, and there was a misunderstanding on either
ends resulting in the impression that what you need could be achievable
through that type of descriptor? Either way, the way you phrased things:
| unless you have to do something so incredibly advanced and exotic as
| a masked update of a field
is very unfair, oversimplifying and misleading.

quoted

Seriously, what is your point? You're complaining about having the
option to write your own microcode for the RISC cores inside the network
controller, when the standard one already comes with a lot of features?
What would you prefer, not having that option?

This is a strawman. None of the features we talked about in this thread,
soft parser for DSA tags or masked header manipulation, should require
custom microcode.

I never made that claim. I was describing our experience with DPAA on
the whole.

I fail to see how we ended up talking about custom FMan microcode then.
I did not bring it up, and it is completely irrelevant to the discussion
about soft parser for DSA.