netdev - Re: [PATCH net-next] net: dsa: mv88e6xxx: Allow dynamic reconfiguration of tag protocol

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 24 Mar 2021 14:01:14 +0100
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Vladimir Oltean <olteanv@...il.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 13:34, Vladimir Oltean <olteanv@...il.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.