All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: DENG Qingfang <dqfext@gmail.com>
Cc: Sean Wang <sean.wang@mediatek.com>,
	Landen Chao <Landen.Chao@mediatek.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	netdev <netdev@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC net-next 2/2] net: dsa: mt7530: trap packets from standalone ports to the CPU
Date: Fri, 30 Jul 2021 19:18:52 +0300	[thread overview]
Message-ID: <20210730161852.4weylgdkcyacxhci@skbuf> (raw)
In-Reply-To: <CALW65jYYmpnDou0dC3=1AjL9tmo_9jqLSWmusJkeqRb4mSwCGQ@mail.gmail.com>

On Fri, Jul 30, 2021 at 11:45:41PM +0800, DENG Qingfang wrote:
> On Fri, Jul 30, 2021 at 12:50 AM Vladimir Oltean <olteanv@gmail.com> wrote:
> > I have the MT7621 GSW, and sadly this reference manual isn't the best in
> > explaining what is and what is not possible. For example, I am still not
> > clear what is meant by "VID1" and "VID0". Is "VID1" the inner (customer)
> > VLAN tag, and "VID0" the outer (service) VLAN tag, or "VID1" means the
> > actual VLAN ID 1?
> >
> > And the bits 3:1 of VAWD1 (VLAN table access register) indicate a FID
> > field per VLAN. I cannot find the piece that you quoted in this manual.
> > But what I expect to happen for a Transparent Port is that the packets
> > are always classified to that port's PVID, and the VLAN Table is looked
> > up with that PVID. There, it will find the FID, which this driver
> > currently always configures as zero. In my manual's description, in the
> > "Transparent Port" chapter, it does explicitly say:
> >
> >         VID0 and VID1 will store PVID as the default VID which is used
> >         to look up the VLAN table.
> >
> > So I get the impression that the phrase "the VLAN table is not applicable"
> > is not quite correct, but I might be wrong...
> 
> Alright, I think I've made some progress.
> In the current code, we only use two combinations to toggle user
> ports' VLAN awareness: one is PCR.PORT_VLAN set to port matrix mode
> with PVC.VLAN_ATTR set to transparent port, the other is PCR.PORT_VLAN
> set to security mode with PVC.VLAN_ATTR set to user port.
> 
> It turns out that only PVC.VLAN_ATTR contributes to VLAN awareness.
> Port matrix mode just skips the VLAN table lookup. The reference
> manual is somehow misleading when describing PORT_VLAN modes (See Page
> 17 of MT7531 Reference Manual, available at
> http://wiki.banana-pi.org/Banana_Pi_BPI-R64#Resources). It states that
> PORT_MEM (VLAN port member) is used for destination if the VLAN table
> lookup hits, but actually it uses **PORT_MEM & PORT_MATRIX** (bitwise
> AND of VLAN port member and port matrix) instead, which means we can
> have two or more separate VLAN-aware bridges with the same PVID and
> traffic won't leak between them.

Ah, but it's not completely misleading. It does say:

	2'b01: Fallback mode

	Enable 802.1Q function for all the received frames.
	Do not discard received frames due to ingress membership violation.
	**Frames whose VID is missed on the VLAN table will be filtered
	by the Port Matrix Member**.

(emphasis mine on the last paragraph)

> So I came up with a solution: Set PORT_VLAN to fallback mode when in
> VLAN-unaware mode, this way, even VLAN-unaware bridges will use
> independent VLAN filtering.

If you did indeed test that the Port Matrix is still used to enforce
separation between ports if the VLAN table _does_ match and we're in
fallback mode, then we should be okay.

> Then assign all standalone ports to a reserved VLAN.

You mean all standalone ports to the same VLAN ID, like 4095, or each
standalone port to a separate reserved VLAN ID? As long as address
learning is disabled on the standalone ports, I guess using a single
VLAN ID like 4095 for all of them is just fine, the Port Matrix will
take care of the rest.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <olteanv@gmail.com>
To: DENG Qingfang <dqfext@gmail.com>
Cc: Sean Wang <sean.wang@mediatek.com>,
	Landen Chao <Landen.Chao@mediatek.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	netdev <netdev@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC net-next 2/2] net: dsa: mt7530: trap packets from standalone ports to the CPU
Date: Fri, 30 Jul 2021 19:18:52 +0300	[thread overview]
Message-ID: <20210730161852.4weylgdkcyacxhci@skbuf> (raw)
In-Reply-To: <CALW65jYYmpnDou0dC3=1AjL9tmo_9jqLSWmusJkeqRb4mSwCGQ@mail.gmail.com>

On Fri, Jul 30, 2021 at 11:45:41PM +0800, DENG Qingfang wrote:
> On Fri, Jul 30, 2021 at 12:50 AM Vladimir Oltean <olteanv@gmail.com> wrote:
> > I have the MT7621 GSW, and sadly this reference manual isn't the best in
> > explaining what is and what is not possible. For example, I am still not
> > clear what is meant by "VID1" and "VID0". Is "VID1" the inner (customer)
> > VLAN tag, and "VID0" the outer (service) VLAN tag, or "VID1" means the
> > actual VLAN ID 1?
> >
> > And the bits 3:1 of VAWD1 (VLAN table access register) indicate a FID
> > field per VLAN. I cannot find the piece that you quoted in this manual.
> > But what I expect to happen for a Transparent Port is that the packets
> > are always classified to that port's PVID, and the VLAN Table is looked
> > up with that PVID. There, it will find the FID, which this driver
> > currently always configures as zero. In my manual's description, in the
> > "Transparent Port" chapter, it does explicitly say:
> >
> >         VID0 and VID1 will store PVID as the default VID which is used
> >         to look up the VLAN table.
> >
> > So I get the impression that the phrase "the VLAN table is not applicable"
> > is not quite correct, but I might be wrong...
> 
> Alright, I think I've made some progress.
> In the current code, we only use two combinations to toggle user
> ports' VLAN awareness: one is PCR.PORT_VLAN set to port matrix mode
> with PVC.VLAN_ATTR set to transparent port, the other is PCR.PORT_VLAN
> set to security mode with PVC.VLAN_ATTR set to user port.
> 
> It turns out that only PVC.VLAN_ATTR contributes to VLAN awareness.
> Port matrix mode just skips the VLAN table lookup. The reference
> manual is somehow misleading when describing PORT_VLAN modes (See Page
> 17 of MT7531 Reference Manual, available at
> http://wiki.banana-pi.org/Banana_Pi_BPI-R64#Resources). It states that
> PORT_MEM (VLAN port member) is used for destination if the VLAN table
> lookup hits, but actually it uses **PORT_MEM & PORT_MATRIX** (bitwise
> AND of VLAN port member and port matrix) instead, which means we can
> have two or more separate VLAN-aware bridges with the same PVID and
> traffic won't leak between them.

Ah, but it's not completely misleading. It does say:

	2'b01: Fallback mode

	Enable 802.1Q function for all the received frames.
	Do not discard received frames due to ingress membership violation.
	**Frames whose VID is missed on the VLAN table will be filtered
	by the Port Matrix Member**.

(emphasis mine on the last paragraph)

> So I came up with a solution: Set PORT_VLAN to fallback mode when in
> VLAN-unaware mode, this way, even VLAN-unaware bridges will use
> independent VLAN filtering.

If you did indeed test that the Port Matrix is still used to enforce
separation between ports if the VLAN table _does_ match and we're in
fallback mode, then we should be okay.

> Then assign all standalone ports to a reserved VLAN.

You mean all standalone ports to the same VLAN ID, like 4095, or each
standalone port to a separate reserved VLAN ID? As long as address
learning is disabled on the standalone ports, I guess using a single
VLAN ID like 4095 for all of them is just fine, the Port Matrix will
take care of the rest.

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <olteanv@gmail.com>
To: DENG Qingfang <dqfext@gmail.com>
Cc: Sean Wang <sean.wang@mediatek.com>,
	Landen Chao <Landen.Chao@mediatek.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	netdev <netdev@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC net-next 2/2] net: dsa: mt7530: trap packets from standalone ports to the CPU
Date: Fri, 30 Jul 2021 19:18:52 +0300	[thread overview]
Message-ID: <20210730161852.4weylgdkcyacxhci@skbuf> (raw)
In-Reply-To: <CALW65jYYmpnDou0dC3=1AjL9tmo_9jqLSWmusJkeqRb4mSwCGQ@mail.gmail.com>

On Fri, Jul 30, 2021 at 11:45:41PM +0800, DENG Qingfang wrote:
> On Fri, Jul 30, 2021 at 12:50 AM Vladimir Oltean <olteanv@gmail.com> wrote:
> > I have the MT7621 GSW, and sadly this reference manual isn't the best in
> > explaining what is and what is not possible. For example, I am still not
> > clear what is meant by "VID1" and "VID0". Is "VID1" the inner (customer)
> > VLAN tag, and "VID0" the outer (service) VLAN tag, or "VID1" means the
> > actual VLAN ID 1?
> >
> > And the bits 3:1 of VAWD1 (VLAN table access register) indicate a FID
> > field per VLAN. I cannot find the piece that you quoted in this manual.
> > But what I expect to happen for a Transparent Port is that the packets
> > are always classified to that port's PVID, and the VLAN Table is looked
> > up with that PVID. There, it will find the FID, which this driver
> > currently always configures as zero. In my manual's description, in the
> > "Transparent Port" chapter, it does explicitly say:
> >
> >         VID0 and VID1 will store PVID as the default VID which is used
> >         to look up the VLAN table.
> >
> > So I get the impression that the phrase "the VLAN table is not applicable"
> > is not quite correct, but I might be wrong...
> 
> Alright, I think I've made some progress.
> In the current code, we only use two combinations to toggle user
> ports' VLAN awareness: one is PCR.PORT_VLAN set to port matrix mode
> with PVC.VLAN_ATTR set to transparent port, the other is PCR.PORT_VLAN
> set to security mode with PVC.VLAN_ATTR set to user port.
> 
> It turns out that only PVC.VLAN_ATTR contributes to VLAN awareness.
> Port matrix mode just skips the VLAN table lookup. The reference
> manual is somehow misleading when describing PORT_VLAN modes (See Page
> 17 of MT7531 Reference Manual, available at
> http://wiki.banana-pi.org/Banana_Pi_BPI-R64#Resources). It states that
> PORT_MEM (VLAN port member) is used for destination if the VLAN table
> lookup hits, but actually it uses **PORT_MEM & PORT_MATRIX** (bitwise
> AND of VLAN port member and port matrix) instead, which means we can
> have two or more separate VLAN-aware bridges with the same PVID and
> traffic won't leak between them.

Ah, but it's not completely misleading. It does say:

	2'b01: Fallback mode

	Enable 802.1Q function for all the received frames.
	Do not discard received frames due to ingress membership violation.
	**Frames whose VID is missed on the VLAN table will be filtered
	by the Port Matrix Member**.

(emphasis mine on the last paragraph)

> So I came up with a solution: Set PORT_VLAN to fallback mode when in
> VLAN-unaware mode, this way, even VLAN-unaware bridges will use
> independent VLAN filtering.

If you did indeed test that the Port Matrix is still used to enforce
separation between ports if the VLAN table _does_ match and we're in
fallback mode, then we should be okay.

> Then assign all standalone ports to a reserved VLAN.

You mean all standalone ports to the same VLAN ID, like 4095, or each
standalone port to a separate reserved VLAN ID? As long as address
learning is disabled on the standalone ports, I guess using a single
VLAN ID like 4095 for all of them is just fine, the Port Matrix will
take care of the rest.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-07-30 16:19 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28 17:53 [RFC net-next 0/2] mt7530 software fallback bridging fix DENG Qingfang
2021-07-28 17:53 ` DENG Qingfang
2021-07-28 17:53 ` DENG Qingfang
2021-07-28 17:53 ` [RFC net-next 1/2] net: dsa: tag_mtk: skip address learning on transmit to standalone ports DENG Qingfang
2021-07-28 17:53   ` DENG Qingfang
2021-07-28 17:53   ` DENG Qingfang
2021-07-28 18:37   ` Vladimir Oltean
2021-07-28 18:37     ` Vladimir Oltean
2021-07-28 18:37     ` Vladimir Oltean
2021-07-30 16:24     ` Vladimir Oltean
2021-07-30 16:24       ` Vladimir Oltean
2021-07-30 16:24       ` Vladimir Oltean
2021-07-30 17:32       ` DENG Qingfang
2021-07-30 17:32         ` DENG Qingfang
2021-07-30 17:32         ` DENG Qingfang
2021-07-30 17:39         ` Vladimir Oltean
2021-07-30 17:39           ` Vladimir Oltean
2021-07-30 17:39           ` Vladimir Oltean
2021-07-30 17:41           ` Vladimir Oltean
2021-07-30 17:41             ` Vladimir Oltean
2021-07-30 17:41             ` Vladimir Oltean
2021-07-30 17:58             ` DENG Qingfang
2021-07-30 17:58               ` DENG Qingfang
2021-07-30 17:58               ` DENG Qingfang
2021-07-30 19:00       ` DENG Qingfang
2021-07-30 19:00         ` DENG Qingfang
2021-07-30 19:00         ` DENG Qingfang
2021-07-30 19:07         ` Vladimir Oltean
2021-07-30 19:07           ` Vladimir Oltean
2021-07-30 19:07           ` Vladimir Oltean
2021-07-30 19:25           ` DENG Qingfang
2021-07-30 19:25             ` DENG Qingfang
2021-07-30 19:25             ` DENG Qingfang
2021-07-30 19:30             ` Vladimir Oltean
2021-07-30 19:30               ` Vladimir Oltean
2021-07-30 19:30               ` Vladimir Oltean
2021-07-28 17:53 ` [RFC net-next 2/2] net: dsa: mt7530: trap packets from standalone ports to the CPU DENG Qingfang
2021-07-28 17:53   ` DENG Qingfang
2021-07-28 17:53   ` DENG Qingfang
2021-07-28 18:47   ` Vladimir Oltean
2021-07-28 18:47     ` Vladimir Oltean
2021-07-28 18:47     ` Vladimir Oltean
2021-07-29 15:28   ` Vladimir Oltean
2021-07-29 15:28     ` Vladimir Oltean
2021-07-29 15:28     ` Vladimir Oltean
2021-07-29 16:11     ` DENG Qingfang
2021-07-29 16:11       ` DENG Qingfang
2021-07-29 16:11       ` DENG Qingfang
2021-07-29 16:50       ` Vladimir Oltean
2021-07-29 16:50         ` Vladimir Oltean
2021-07-29 16:50         ` Vladimir Oltean
2021-07-30 15:45         ` DENG Qingfang
2021-07-30 15:45           ` DENG Qingfang
2021-07-30 15:45           ` DENG Qingfang
2021-07-30 15:58           ` DENG Qingfang
2021-07-30 15:58             ` DENG Qingfang
2021-07-30 15:58             ` DENG Qingfang
2021-07-30 16:18           ` Vladimir Oltean [this message]
2021-07-30 16:18             ` Vladimir Oltean
2021-07-30 16:18             ` Vladimir Oltean
2021-07-30 17:21             ` DENG Qingfang
2021-07-30 17:21               ` DENG Qingfang
2021-07-30 17:21               ` DENG Qingfang
2021-07-30 17:35               ` Vladimir Oltean
2021-07-30 17:35                 ` Vladimir Oltean
2021-07-30 17:35                 ` Vladimir Oltean
2021-07-30 17:51                 ` DENG Qingfang
2021-07-30 17:51                   ` DENG Qingfang
2021-07-30 17:51                   ` DENG Qingfang
2021-07-28 18:08 ` [RFC net-next 0/2] mt7530 software fallback bridging fix Vladimir Oltean
2021-07-28 18:08   ` Vladimir Oltean
2021-07-28 18:08   ` Vladimir Oltean

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=20210730161852.4weylgdkcyacxhci@skbuf \
    --to=olteanv@gmail.com \
    --cc=Landen.Chao@mediatek.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=sean.wang@mediatek.com \
    --cc=vivien.didelot@gmail.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.