netdev - Re: [PATCH iproute2-next v3 1/2] dcb: add new pcp-prio parameter to dcb app

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] [day] [month] [year] [list]

Date:   Tue, 6 Dec 2022 09:55:33 +0100
From:   Petr Machata <petrm@...dia.com>
To:     <Daniel.Machon@...rochip.com>
CC:     <stephen@...workplumber.org>, <netdev@...r.kernel.org>,
        <dsahern@...nel.org>, <petrm@...dia.com>,
        <maxime.chevallier@...tlin.com>, <vladimir.oltean@....com>,
        <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH iproute2-next v3 1/2] dcb: add new pcp-prio parameter to
 dcb app


<Daniel.Machon@...rochip.com> writes:

>> On Mon, 5 Dec 2022 09:19:06 +0000
>> <Daniel.Machon@...rochip.com> wrote:
>> 
>> > > > Trying to understand your comment.
>> > > >
>> > > > Are you talking about not producing any JSON output with the symbolic
>> > > > PCP values? eg. ["1de", 1] -> [8, 1]. So basically print with PRINT_FP
>> > > > in case of printing in JSON context?
>> > >
>> > > What does output look like in json and non-json versions?
>> >
>> > non-JSON: pcp-prio 1de:1
>> > JSON    : {"pcp_prio":[["1de",1]]}
>> 
>> Would the JSON be better as:
>>         { "pcp_prio" :[ { "1de":1 } ] }
>> 
>> It looks like the PCP values are both unique and used in a name/value manner.
>
> In this case I think it would be best to stay consistent with the rest
> of the dcb app code. All priority mappings are printed using the
> dcb_app_print_filtered() (now also the pcp-prio), which creates an
> array, for whatever reason.

The reason is that APP mappings are not unique. It is OK to have rules
for both 1de:1 and 1de:2. And 2de:1 and 2de:2 too, it's a full m:n
relationship. A JSON dictionary would not work well for this purpose.
(It's not technically forbidden to have duplicate keys in a JSON
dictionary, just discouraged, i.e. SHOULD NOT rather than SHALL NOT, but
e.g. jq then doesn't let you work with both entries.)