Date:   Wed, 24 Mar 2021 13:34:03 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: dsa: mv88e6xxx: Allow dynamic
 reconfiguration of tag protocol

On Wed, Mar 24, 2021 at 11:52:49AM +0100, Tobias Waldekranz wrote:
> >> 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 :)
> 
> > 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
(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
that it costs money, especially considering the fact that you're going
to need heaps of support for it anyway?

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.

Powered by blists - more mailing lists