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

[Nitin Shetty J <nshettyj@marvell.com>]

On 2026-06-27 at 06:20:38, Harshitha Ramamurthy (hramamurthy@google.com) wrote:
> On Thu, Jun 25, 2026 at 11:24 PM <nshettyj@marvell.com> wrote:
> >
> > From: Suman Ghosh <sumang@marvell.com>
> >
> > 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@marvell.com>
> > Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
> >
> > ---
> > 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
> >
> >
>