From: Kurt Kanzenbach <kurt@linutronix.de>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Vivien Didelot <vivien.didelot@gmail.com>
Subject: Re: [PATCH net-next 10/11] net: dsa: tag_8021q: manage RX VLANs dynamically at bridge join/leave time
Date: Wed, 21 Jul 2021 12:38:16 +0200 [thread overview]
Message-ID: <87fsw8vtnr.fsf@kurt> (raw)
In-Reply-To: <20210721094155.aoikj4ghf2d3a4ap@skbuf>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
On Wed Jul 21 2021, Vladimir Oltean wrote:
> Hi Kurt,
>
> On Wed, Jul 21, 2021 at 11:06:58AM +0200, Kurt Kanzenbach wrote:
>> Hi Vladimir,
>>
>> On Mon Jul 19 2021, Vladimir Oltean wrote:
>> > This is not to say that the reason for the change in this patch is to
>> > satisfy the hellcreek and similar use cases, that is merely a nice side
>> > effect.
>>
>> Is it possible to use tag_8021q for port separation use cases now? I'd
>> be interested in it if that results in a simplified hellcreek
>> implementation :).
>
> Yes, but I still don't think it is worth it.
>
> At the moment, if I'm not mistaken, hellcreek reserves 3 VLANs or so,
> from 4093 to 4095. Whereas tag_8021q will reserve the entire range from
> 1024 to 3071. The VLAN IDs used by tag_8021q have a bitwise meaning of
> their own, so that range cannot be simply shifted (at least not easily).
>
> If you only want to use tag_8021q for port separation in standalone
> mode, and not really as a tagging protocol (tag_hellcreek.c will not see
> the tag_8021q VLANs), I suppose that restriction can be lifted somewhat:
> (a) tag_8021q can only reserve RX VLANs but not TX VLANs (that would
> reduce the reserved range from 1024-3071 to 1024-2047)
> (b) tag_8021q can only reserve RX VLANs for the actual ds->num_ports and
> ds->index values in use (which would further reduce the range to
> 1024-1026 in your case)
>
> In terms of driver implementation, not a lot would go away. The current
> places where you handle events, like hellcreek_setup_vlan_membership(),
> will still remain the way they are, but they will just set up a VLAN
> provided by tag_8021q instead of one provided by hellcreek_private_vid().
>
> Six of one, half a dozen of the other.
OK. Seems like it's not worth it.
Thanks,
Kurt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
next prev parent reply other threads:[~2021-07-21 11:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-19 17:14 [PATCH net-next 00/11] Proper cross-chip support for tag_8021q Vladimir Oltean
2021-07-19 17:14 ` [PATCH net-next 01/11] net: dsa: sja1105: delete the best_effort_vlan_filtering mode Vladimir Oltean
2021-07-19 17:14 ` [PATCH net-next 02/11] net: dsa: tag_8021q: use "err" consistently instead of "rc" Vladimir Oltean
2021-07-19 17:14 ` [PATCH net-next 03/11] net: dsa: tag_8021q: use symbolic error names Vladimir Oltean
2021-07-19 17:14 ` [PATCH net-next 04/11] net: dsa: tag_8021q: remove struct packet_type declaration Vladimir Oltean
2021-07-19 17:14 ` [PATCH net-next 05/11] net: dsa: tag_8021q: create dsa_tag_8021q_{register,unregister} helpers Vladimir Oltean
2021-07-19 17:14 ` [PATCH net-next 06/11] net: dsa: build tag_8021q.c as part of DSA core Vladimir Oltean
2021-07-19 17:14 ` [PATCH net-next 07/11] net: dsa: let the core manage the tag_8021q context Vladimir Oltean
2021-07-19 17:14 ` [PATCH net-next 08/11] net: dsa: make tag_8021q operations part of the core Vladimir Oltean
2021-07-19 17:14 ` [PATCH net-next 09/11] net: dsa: tag_8021q: absorb dsa_8021q_setup into dsa_tag_8021q_{,un}register Vladimir Oltean
2021-07-19 17:14 ` [PATCH net-next 10/11] net: dsa: tag_8021q: manage RX VLANs dynamically at bridge join/leave time Vladimir Oltean
2021-07-21 9:06 ` Kurt Kanzenbach
2021-07-21 9:41 ` Vladimir Oltean
2021-07-21 10:38 ` Kurt Kanzenbach [this message]
2021-07-19 17:14 ` [PATCH net-next 11/11] net: dsa: tag_8021q: add proper cross-chip notifier support Vladimir Oltean
2021-07-20 14:00 ` [PATCH net-next 00/11] Proper cross-chip support for tag_8021q patchwork-bot+netdevbpf
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=87fsw8vtnr.fsf@kurt \
--to=kurt@linutronix.de \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@gmail.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.