[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87edw7y93y.fsf@nvidia.com>
Date: Mon, 19 Sep 2022 11:45:41 +0200
From: Petr Machata <petrm@...dia.com>
To: Daniel Machon <daniel.machon@...rochip.com>
CC: <netdev@...r.kernel.org>, <Allan.Nielsen@...rochip.com>,
<UNGLinuxDriver@...rochip.com>, <maxime.chevallier@...tlin.com>,
<vladimir.oltean@....com>, <petrm@...dia.com>, <kuba@...nel.org>,
<vinicius.gomes@...el.com>, <thomas.petazzoni@...tlin.com>
Subject: Re: [RFC PATCH v2 net-next 1/2] net: dcb: add new pcp selector to
app object
Daniel Machon <daniel.machon@...rochip.com> writes:
> diff --git a/include/uapi/linux/dcbnl.h b/include/uapi/linux/dcbnl.h
> index a791a94013a6..8eab16e5bc13 100644
> --- a/include/uapi/linux/dcbnl.h
> +++ b/include/uapi/linux/dcbnl.h
> @@ -217,6 +217,7 @@ struct cee_pfc {
> #define IEEE_8021QAZ_APP_SEL_DGRAM 3
> #define IEEE_8021QAZ_APP_SEL_ANY 4
> #define IEEE_8021QAZ_APP_SEL_DSCP 5
> +#define IEEE_8021QAZ_APP_SEL_PCP 255
>
> /* This structure contains the IEEE 802.1Qaz APP managed object. This
> * object is also used for the CEE std as well.
One more thought: please verify how this behaves with openlldpad.
It's a fairly major user of this API.
I guess it is OK if it refuses to run or bails out in face of the PCP
APP entries. On its own it will never introduce them, so this clear and
noisy diagnostic when a user messes with the system through a different
channels is OK IMHO.
But it shouldn't silently reinterpret the 255 to mean something else.
Powered by blists - more mailing lists