From: Paolo Abeni <pabeni@redhat.com>
To: Pawel Dembicki <paweldembicki@gmail.com>, netdev@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Russell King <linux@armlinux.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2] net: dsa: vsc73xx: implement FDB operations
Date: Tue, 27 Aug 2024 12:57:35 +0200 [thread overview]
Message-ID: <2564cd0a-c236-427a-abd7-e9933adff5cc@redhat.com> (raw)
In-Reply-To: <20240822142344.354114-1-paweldembicki@gmail.com>
On 8/22/24 16:23, Pawel Dembicki wrote:
> This commit introduces implementations of three functions:
> .port_fdb_dump
> .port_fdb_add
> .port_fdb_del
>
> The FDB database organization is the same as in other old Vitesse chips:
> It has 2048 rows and 4 columns (buckets). The row index is calculated by
> the hash function 'vsc73xx_calc_hash' and the FDB entry must be placed
> exactly into row[hash]. The chip selects the bucket number by itself.
>
> Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
The patch LGTM, but I think you can deduplicate the code a bit, creating
a few additional helpers.
> +static int vsc73xx_port_read_mac_table_row(struct vsc73xx *vsc, u16 index,
> + struct vsc73xx_fdb *fdb)
> +{
> + int ret, i;
> + u32 val;
> +
> + if (!fdb)
> + return -EINVAL;
> + if (index >= VSC73XX_NUM_FDB_ROWS)
> + return -EINVAL;
> +
> + for (i = 0; i < VSC73XX_NUM_BUCKETS; i++) {
> + ret = vsc73xx_write(vsc, VSC73XX_BLOCK_ANALYZER, 0,
> + VSC73XX_MACTINDX,
> + (i ? 0 : VSC73XX_MACTINDX_SHADOW) |
> + FIELD_PREP(VSC73XX_MACTINDX_BUCKET_MSK, i) |
> + index);
> + if (ret)
> + return ret;
> +
> + ret = vsc73xx_port_wait_for_mac_table_cmd(vsc);
> + if (ret)
> + return ret;
the sequence:
vsc73xx_write(vsc, VSC73XX_BLOCK_ANALYZER, 0, ...)
vsc73xx_port_wait_for_mac_table_cmd()
could have its own helper
> + ret = vsc73xx_update_bits(vsc, VSC73XX_BLOCK_ANALYZER, 0,
> + VSC73XX_MACACCESS,
> + VSC73XX_MACACCESS_CMD_MASK,
> + VSC73XX_MACACCESS_CMD_READ_ENTRY);
> + if (ret)
> + return ret;
> +
> + ret = vsc73xx_port_wait_for_mac_table_cmd(vsc);
> + if (ret)
> + return ret;
and even:
vsc73xx_update_bits(vsc, VSC73XX_BLOCK_ANALYZER, 0, ...)
vsc73xx_port_wait_for_mac_table_cmd()
[...]
> +static int vsc73xx_fdb_del_entry(struct vsc73xx *vsc, int port,
> + const unsigned char *addr, u16 vid)
> +{
> + struct vsc73xx_fdb fdb[VSC73XX_NUM_BUCKETS];
> + u16 hash = vsc73xx_calc_hash(addr, vid);
> + int bucket, ret;
> +
> + mutex_lock(&vsc->fdb_lock);
> +
> + ret = vsc73xx_port_read_mac_table_row(vsc, hash, fdb);
> + if (ret)
> + goto err;
> +
> + for (bucket = 0; bucket < VSC73XX_NUM_BUCKETS; bucket++) {
> + if (fdb[bucket].valid && fdb[bucket].port == port &&
> + ether_addr_equal(addr, fdb[bucket].mac))
> + break;
> + }
> +
> + if (bucket == VSC73XX_NUM_BUCKETS) {
> + /* Can't find MAC in MAC table */
> + ret = -ENODATA;
> + goto err;
> + }
> +
> + ret = vsc73xx_fdb_insert_mac(vsc, addr, vid);
> + if (ret)
> + goto err;
> +
> + ret = vsc73xx_write(vsc, VSC73XX_BLOCK_ANALYZER, 0, VSC73XX_MACTINDX,
> + hash);
> + if (ret)
> + goto err;
> +
> + ret = vsc73xx_port_wait_for_mac_table_cmd(vsc);
> + if (ret)
> + goto err;
> +
> + ret = vsc73xx_update_bits(vsc, VSC73XX_BLOCK_ANALYZER, 0,
> + VSC73XX_MACACCESS,
> + VSC73XX_MACACCESS_CMD_MASK,
> + VSC73XX_MACACCESS_CMD_FORGET);
> + if (ret)
> + goto err;
> +
> + ret = vsc73xx_port_wait_for_mac_table_cmd(vsc);
AFAICS both fdb_add and fdb_del use the same sequence:
vsc73xx_fdb_insert_mac()
vsc73xx_write(... VSC73XX_MACTINDX, hash);
vsc73xx_port_wait_for_mac_table_cmd
vsc73xx_update_bits(... <variable part>)
vsc73xx_port_wait_for_mac_table_cmd()
perhaps it would be worthy to factor it out - also using the above
mentioned helpers.
Thanks,
Paolo
prev parent reply other threads:[~2024-08-27 10:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-22 14:23 [PATCH net-next v2] net: dsa: vsc73xx: implement FDB operations Pawel Dembicki
2024-08-24 14:02 ` Simon Horman
2024-08-27 10:57 ` Paolo Abeni [this message]
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=2564cd0a-c236-427a-abd7-e9933adff5cc@redhat.com \
--to=pabeni@redhat.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=paweldembicki@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.