On Wed, Mar 24, 2021 at 13:34, Vladimir Oltean <olte...@gmail.com> wrote: > 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
This is not the story we were told. > (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. > 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. > 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.
