From: Petr Machata <petrm@nvidia.com>
To: <Daniel.Machon@microchip.com>
Cc: <vladimir.oltean@nxp.com>, <netdev@vger.kernel.org>,
<Allan.Nielsen@microchip.com>, <UNGLinuxDriver@microchip.com>,
<maxime.chevallier@bootlin.com>, <petrm@nvidia.com>,
<kuba@kernel.org>, <vinicius.gomes@intel.com>,
<thomas.petazzoni@bootlin.com>
Subject: Re: [RFC PATCH net-next 2/2] net: dcb: add new apptrust attribute
Date: Mon, 12 Sep 2022 18:30:08 +0200 [thread overview]
Message-ID: <874jxceemc.fsf@nvidia.com> (raw)
In-Reply-To: <Yx7b5Jg051jFhLea@DEN-LT-70577>
<Daniel.Machon@microchip.com> writes:
> Den Fri, Sep 09, 2022 at 12:29:50PM +0000 skrev Vladimir Oltean:
>
>> Let's say I have a switch which only looks at VLAN PCP/DEI if the bridge
>> vlan_filtering setting is enabled (otherwise, the switch is completely
>> VLAN unaware, including for QoS purposes).
>>
>> Would it be ok to report through ieee_getapptrust() that the PCP
>> selector is trusted when under a vlan_filtering bridge, not trusted when
>> not under a vlan_filtering bridge, and deny changes to ieee_setapptrust()
>> for the PCP selector? I see the return value is not cached anywhere
>> within the kernel, just passed to the user.
>
> Therefore, in your particular case, with the vlan_filtering on/off,
> yes that would be OK IMO. Any concerns?
Yeah, it would make sense to me. With the 802.1q bridge, the reported
trust level would be [PCP], with 802.1d it would be [].
As a service to the user, I would accept set requests that just reassert
the only valid configuration, but otherwise it sounds OK to me.
next prev parent reply other threads:[~2022-09-12 16:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 12:04 [RFC PATCH net-next 0/2] Add PCP selector and new APPTRUST attribute Daniel Machon
2022-09-08 12:04 ` [RFC PATCH net-next 1/2] net: dcb: add new pcp selector to app object Daniel Machon
2022-09-12 16:15 ` Petr Machata
2022-09-13 6:33 ` Daniel.Machon
2022-09-08 12:04 ` [RFC PATCH net-next 2/2] net: dcb: add new apptrust attribute Daniel Machon
2022-09-09 12:29 ` Vladimir Oltean
2022-09-12 7:03 ` Daniel.Machon
2022-09-12 16:30 ` Petr Machata [this message]
2022-09-12 17:16 ` Vladimir Oltean
2022-09-12 14:31 ` Petr Machata
2022-09-13 9:01 ` Daniel.Machon
2022-09-13 11:25 ` Petr Machata
2022-09-13 19:22 ` Daniel.Machon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jxceemc.fsf@nvidia.com \
--to=petrm@nvidia.com \
--cc=Allan.Nielsen@microchip.com \
--cc=Daniel.Machon@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=kuba@kernel.org \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=vinicius.gomes@intel.com \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.