From: Vladimir Oltean <olteanv@gmail.com>
To: arinc.unal@arinc9.com
Cc: "Daniel Golle" <daniel@makrotopia.org>,
"DENG Qingfang" <dqfext@gmail.com>,
"Sean Wang" <sean.wang@mediatek.com>,
"Andrew Lunn" <andrew@lunn.ch>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Alvin Šipraga" <ALSI@bang-olufsen.dk>,
"Frank Wunderlich" <frank-w@public-files.de>,
"Bartel Eerdekens" <bartel.eerdekens@constell8.be>,
mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH net RFC] net: dsa: mt7530: fix link-local frames that ingress vlan filtering ports
Date: Fri, 2 Feb 2024 01:26:19 +0200 [thread overview]
Message-ID: <20240201232619.nsmm7lvafuem2gou@skbuf> (raw)
In-Reply-To: <65bbf40d.170a0220.a87f4.becdSMTPIN_ADDED_BROKEN@mx.google.com> <65bbf40d.170a0220.a87f4.becdSMTPIN_ADDED_BROKEN@mx.google.com>
On Thu, Feb 01, 2024 at 10:13:39PM +0300, Arınç ÜNAL via B4 Relay wrote:
> One remaining limitation is that the ingress port must have a PVID assigned
> to it for the frame to be trapped to the CPU port. A PVID is set by default
> on vlan aware and vlan unaware ports. However, when the network interface
> that pertains to the ingress port is attached to a vlan_filtering enabled
> bridge, the user can remove the PVID assignment from it which would prevent
> the link-local frames from being trapped to the CPU port.
>
> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> ---
> I couldn't figure out a way to bypass VLAN table lookup for link-local
> frames to directly trap them to the CPU port. The CPU port is hardcoded for
> MT7530. For MT7531 and the switch on the MT7988 SoC, it depends on the port
> matrix to choose the CPU port to trap the frames to. Port matrix and VLAN
> table seem to go hand in hand so I don't know if this would even be
> possible.
>
> If possible to implement, link-local frames must not be influenced by the
> VLAN table. They must always be trapped to the CPU port, and trapped
> untagged.
Isn't this, in effect, what the "Leaky VLAN Enable" bit does?
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <olteanv@gmail.com>
To: arinc.unal@arinc9.com
Cc: "Andrew Lunn" <andrew@lunn.ch>,
"Florian Fainelli" <f.fainelli@gmail.com>,
erkin.bozoglu@xeront.com, "Sean Wang" <sean.wang@mediatek.com>,
"Daniel Golle" <daniel@makrotopia.org>,
linux-kernel@vger.kernel.org, "DENG Qingfang" <dqfext@gmail.com>,
"Eric Dumazet" <edumazet@google.com>,
netdev@vger.kernel.org, linux-mediatek@lists.infradead.org,
"Bartel Eerdekens" <bartel.eerdekens@constell8.be>,
"Alvin Šipraga" <ALSI@bang-olufsen.dk>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
mithat.guner@xeront.com, "David S. Miller" <davem@davemloft.net>,
linux-arm-kernel@lists.infradead.org,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH net RFC] net: dsa: mt7530: fix link-local frames that ingress vlan filtering ports
Date: Fri, 2 Feb 2024 01:26:19 +0200 [thread overview]
Message-ID: <20240201232619.nsmm7lvafuem2gou@skbuf> (raw)
In-Reply-To: <65bbf40d.170a0220.a87f4.becdSMTPIN_ADDED_BROKEN@mx.google.com> <65bbf40d.170a0220.a87f4.becdSMTPIN_ADDED_BROKEN@mx.google.com>
On Thu, Feb 01, 2024 at 10:13:39PM +0300, Arınç ÜNAL via B4 Relay wrote:
> One remaining limitation is that the ingress port must have a PVID assigned
> to it for the frame to be trapped to the CPU port. A PVID is set by default
> on vlan aware and vlan unaware ports. However, when the network interface
> that pertains to the ingress port is attached to a vlan_filtering enabled
> bridge, the user can remove the PVID assignment from it which would prevent
> the link-local frames from being trapped to the CPU port.
>
> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> ---
> I couldn't figure out a way to bypass VLAN table lookup for link-local
> frames to directly trap them to the CPU port. The CPU port is hardcoded for
> MT7530. For MT7531 and the switch on the MT7988 SoC, it depends on the port
> matrix to choose the CPU port to trap the frames to. Port matrix and VLAN
> table seem to go hand in hand so I don't know if this would even be
> possible.
>
> If possible to implement, link-local frames must not be influenced by the
> VLAN table. They must always be trapped to the CPU port, and trapped
> untagged.
Isn't this, in effect, what the "Leaky VLAN Enable" bit does?
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <olteanv@gmail.com>
To: arinc.unal@arinc9.com
Cc: "Daniel Golle" <daniel@makrotopia.org>,
"DENG Qingfang" <dqfext@gmail.com>,
"Sean Wang" <sean.wang@mediatek.com>,
"Andrew Lunn" <andrew@lunn.ch>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Alvin Šipraga" <ALSI@bang-olufsen.dk>,
"Frank Wunderlich" <frank-w@public-files.de>,
"Bartel Eerdekens" <bartel.eerdekens@constell8.be>,
mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH net RFC] net: dsa: mt7530: fix link-local frames that ingress vlan filtering ports
Date: Fri, 2 Feb 2024 01:26:19 +0200 [thread overview]
Message-ID: <20240201232619.nsmm7lvafuem2gou@skbuf> (raw)
In-Reply-To: <65bbf40d.170a0220.a87f4.becdSMTPIN_ADDED_BROKEN@mx.google.com> <65bbf40d.170a0220.a87f4.becdSMTPIN_ADDED_BROKEN@mx.google.com>
On Thu, Feb 01, 2024 at 10:13:39PM +0300, Arınç ÜNAL via B4 Relay wrote:
> One remaining limitation is that the ingress port must have a PVID assigned
> to it for the frame to be trapped to the CPU port. A PVID is set by default
> on vlan aware and vlan unaware ports. However, when the network interface
> that pertains to the ingress port is attached to a vlan_filtering enabled
> bridge, the user can remove the PVID assignment from it which would prevent
> the link-local frames from being trapped to the CPU port.
>
> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> ---
> I couldn't figure out a way to bypass VLAN table lookup for link-local
> frames to directly trap them to the CPU port. The CPU port is hardcoded for
> MT7530. For MT7531 and the switch on the MT7988 SoC, it depends on the port
> matrix to choose the CPU port to trap the frames to. Port matrix and VLAN
> table seem to go hand in hand so I don't know if this would even be
> possible.
>
> If possible to implement, link-local frames must not be influenced by the
> VLAN table. They must always be trapped to the CPU port, and trapped
> untagged.
Isn't this, in effect, what the "Leaky VLAN Enable" bit does?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-01 23:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <65bbf40d.170a0220.a87f4.becdSMTPIN_ADDED_BROKEN@mx.google.com>
2024-02-01 22:59 ` [PATCH net RFC] net: dsa: mt7530: fix link-local frames that ingress vlan filtering ports Vladimir Oltean
2024-02-01 22:59 ` Vladimir Oltean
2024-02-01 22:59 ` Vladimir Oltean
2024-02-02 9:11 ` Arınç ÜNAL
2024-02-02 9:11 ` Arınç ÜNAL
2024-02-02 9:11 ` Arınç ÜNAL
2024-02-05 20:24 ` Konstantin Ryabitsev
2024-02-05 20:24 ` Konstantin Ryabitsev
2024-02-05 20:24 ` Konstantin Ryabitsev
2024-02-01 23:26 ` Vladimir Oltean [this message]
2024-02-01 23:26 ` Vladimir Oltean
2024-02-01 23:26 ` Vladimir Oltean
2024-02-16 1:24 ` Vladimir Oltean
2024-02-16 1:24 ` Vladimir Oltean
2024-02-16 1:24 ` Vladimir Oltean
2024-02-16 10:47 ` Arınç ÜNAL
2024-02-16 10:47 ` Arınç ÜNAL
2024-02-16 10:47 ` Arınç ÜNAL
2024-02-01 19:13 Arınç ÜNAL
-- strict thread matches above, loose matches on Subject: below --
2024-02-01 19:13 Arınç ÜNAL via B4 Relay
2024-02-01 19:13 ` Arınç ÜNAL via B4 Relay
2024-02-01 19:13 ` Arınç ÜNAL via B4 Relay
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=20240201232619.nsmm7lvafuem2gou@skbuf \
--to=olteanv@gmail.com \
--cc=ALSI@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=arinc.unal@arinc9.com \
--cc=bartel.eerdekens@constell8.be \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=erkin.bozoglu@xeront.com \
--cc=f.fainelli@gmail.com \
--cc=frank-w@public-files.de \
--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=mithat.guner@xeront.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sean.wang@mediatek.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.