From: Vladimir Oltean <olteanv@gmail.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>,
Andrew Lunn <andrew@lunn.ch>, Eric Dumazet <edumazet@google.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Woojung Huh <woojung.huh@microchip.com>,
Arun Ramadoss <arun.ramadoss@microchip.com>,
kernel@pengutronix.de, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, UNGLinuxDriver@microchip.com
Subject: Re: [PATCH net-next v1 2/7] net: dsa: microchip: ksz8: Implement add/del_fdb and use static MAC table operations
Date: Tue, 4 Apr 2023 15:50:02 +0300 [thread overview]
Message-ID: <20230404125002.dv2f4foojhy43dkx@skbuf> (raw)
In-Reply-To: <20230404121911.GA4044@pengutronix.de>
On Tue, Apr 04, 2023 at 02:19:11PM +0200, Oleksij Rempel wrote:
> If I compare KSZ879CLX and KSZ8873MLL datasheets, i do not see direct
> answer. The only reason I can imagine is the size of static MAC table.
> All KSZ88xx and KSZ87xx variants have only 8 entries. One is already
> used for STP (even if STP is not enabled, can be optimized). If
> BRIDGE_VLAN compiled, each local address will be configured 2 times.
> So, depending on system configuration the static MAC table will full
> very soon.
Yikes. KSZ8765 has num_statics = 8 and port_cnt = 5 (so 4 user ports I
assume). So if all 4 user ports had their own MAC address, it would
simply not be possible to put them under a VLAN-aware bridge, since that
would consume 2 BR_FDB_LOCAL entries for each port, so the static MAC
table would be full even without taking the bridge's MAC address into
consideration.
Even with CONFIG_BRIDGE_VLAN_FILTERING turned off or with the bridge
option vlan_default_pvid = 0, this would still consume 4 BR_FDB_LOCAL
entries + one for the bridge's MAC address + 1 for STP, leaving only 2
entries usable for *both* bridge fdb, *and* bridge mdb.
I haven't opened the datasheets of these chips. Is it possible to use
the dynamic MAC table to store static(-ish) entries?
next prev parent reply other threads:[~2023-04-04 12:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-04 10:18 [PATCH net-next v1 0/7] net: dsa: microchip: ksz8: Enhance static MAC table operations and error handling Oleksij Rempel
2023-04-04 10:18 ` [PATCH net-next v1 1/7] net: dsa: microchip: ksz8: Separate static MAC table operations for code reuse Oleksij Rempel
2023-04-04 11:28 ` Vladimir Oltean
2023-04-04 10:18 ` [PATCH net-next v1 2/7] net: dsa: microchip: ksz8: Implement add/del_fdb and use static MAC table operations Oleksij Rempel
2023-04-04 11:31 ` Vladimir Oltean
2023-04-04 12:19 ` Oleksij Rempel
2023-04-04 12:50 ` Vladimir Oltean [this message]
2023-04-04 13:06 ` Oleksij Rempel
2023-04-04 10:18 ` [PATCH net-next v1 3/7] net: dsa: microchip: ksz8: Make ksz8_r_sta_mac_table() static Oleksij Rempel
2023-04-04 11:34 ` Vladimir Oltean
2023-04-04 15:11 ` Arun.Ramadoss
2023-04-04 16:00 ` Oleksij Rempel
2023-04-04 10:18 ` [PATCH net-next v1 4/7] net: dsa: microchip: ksz8_r_sta_mac_table(): Avoid using error code for empty entries Oleksij Rempel
2023-04-04 11:58 ` Vladimir Oltean
2023-04-04 10:18 ` [PATCH net-next v1 5/7] net: dsa: microchip: ksz8_r_sta_mac_table(): Utilize error values from read/write functions Oleksij Rempel
2023-04-04 15:12 ` Arun.Ramadoss
2023-04-04 10:18 ` [PATCH net-next v1 6/7] net: dsa: microchip: Make ksz8_w_sta_mac_table() static Oleksij Rempel
2023-04-04 15:13 ` Arun.Ramadoss
2023-04-04 10:18 ` [PATCH net-next v1 7/7] net: dsa: microchip: Utilize error values in ksz8_w_sta_mac_table() Oleksij Rempel
2023-04-04 15:15 ` Arun.Ramadoss
2023-04-06 9:40 ` [PATCH net-next v1 0/7] net: dsa: microchip: ksz8: Enhance static MAC table operations and error handling 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=20230404125002.dv2f4foojhy43dkx@skbuf \
--to=olteanv@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=arun.ramadoss@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=woojung.huh@microchip.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.