Re: [PATCH net v2] octeontx2-pf: check DMAC extraction support before filtering

From: Nitin Shetty J

Date: Mon Jun 29 2026 - 04:43:01 EST


On 2026-06-27 at 06:20:38, Harshitha Ramamurthy (hramamurthy@xxxxxxxxxx) wrote:
> On Thu, Jun 25, 2026 at 11:24 PM <nshettyj@xxxxxxxxxxx> wrote:
> >
> > From: Suman Ghosh <sumang@xxxxxxxxxxx>
> >
> > Currently, configuring a VF MAC address via the PF (e.g., 'ip link
> > set <pf> vf 0 mac <mac>') blindly attempts to install a DMAC-based
> > hardware filter. However, the hardware parser profile might not
> > support DMAC extraction.
> >
> > Check if the hardware parsing profile supports DMAC extraction
> > before adding the filter. Additionally, emit a warning message
> > to inform the operator if the MAC filter installation fails due
> > to missing DMAC extraction support.
> >
> > Fixes: f0c2982aaf98 ("octeontx2-pf: Add support for SR-IOV management functions")
> > Signed-off-by: Suman Ghosh <sumang@xxxxxxxxxxx>
> > Signed-off-by: Nitin Shetty J <nshettyj@xxxxxxxxxxx>
> >
> > ---
> > v2:
> > - Move the DMAC extraction check from otx2_set_vf_mac() into
> > otx2_do_set_vf_mac() which already holds pf->mbox.lock, so all
> > mbox operations are under a single lock/unlock pair. All error
> > paths now use the existing goto-out pattern, eliminating the
> > scattered mutex_unlock() + return calls from v1.
> > - Return -EOPNOTSUPP instead of 0 when DMAC extraction is not
> > supported, so the caller gets an explicit error rather than a
> > silent success.
>
> Please ensure a minimum of 24 hr gap before posting a new revision and
> also don't post patches in reply to a previous posting as documented
> in:
>
> https://www.kernel.org/doc/html/next/process/maintainer-netdev.html
>
Apologies for the process oversight. I will ensure a 24-hour window
before posting v3, and I will submit it as a new thread.

> > ---
> > .../ethernet/marvell/octeontx2/nic/otx2_pf.c | 33 +++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> > index b63df5737ff2..dc7e4a225dd0 100644
> > --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> > +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> > @@ -2517,10 +2517,43 @@ EXPORT_SYMBOL(otx2_config_hwtstamp_set);
> >
> > static int otx2_do_set_vf_mac(struct otx2_nic *pf, int vf, const u8 *mac)
> > {
> > + struct npc_get_field_status_req *freq;
> > + struct npc_get_field_status_rsp *frsp;
> > struct npc_install_flow_req *req;
> > int err;
> >
> > mutex_lock(&pf->mbox.lock);
> > +
> > + /* Skip installing the DMAC filter if the hardware parser profile
> > + * does not support DMAC extraction.
> > + */
> > + freq = otx2_mbox_alloc_msg_npc_get_field_status(&pf->mbox);
> > + if (!freq) {
> > + err = -ENOMEM;
> > + goto out;
> > + }
>
> I noticed that otx2_set_vf_mac() copies the MAC address into the vf
> config structure before the programming is successful. Is that
> intended?
>
Good catch. This is not intended behavior. I will fix it in next V3.

> > +
> > + freq->field = NPC_DMAC;
> > + if (otx2_sync_mbox_msg(&pf->mbox)) {
> > + err = -EINVAL;
> > + goto out;
> > + }
> > +
> > + frsp = (struct npc_get_field_status_rsp *)otx2_mbox_get_rsp
> > + (&pf->mbox.mbox, 0, &freq->hdr);
> > + if (IS_ERR(frsp)) {
> > + err = PTR_ERR(frsp);
> > + goto out;
> > + }
> > +
> > + if (!frsp->enable) {
> > + netdev_warn(pf->netdev,
> > + "VF %d MAC filter not installed: DMAC extraction not supported by parser profile\n",
> > + vf);
>
> Would a netdev_warn_ratelimited() be better here to avoid spamming the log?
>
Since this block is only executed when we use the 'ip link' command
and does not sit on the runtime hot data path, the potential
for log spam is negligible. I prefer to retain netdev_warn()
so the operator receives an explicit warning when command fails.

> > + err = -EOPNOTSUPP;
> > + goto out;
> > + }
> > +
> > req = otx2_mbox_alloc_msg_npc_install_flow(&pf->mbox);
> > if (!req) {
> > err = -ENOMEM;
> > --
> > 2.48.1
> >
> >
>