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

On 2026-06-27 at 06:20:38, Harshitha Ramamurthy (hramamurthy@google.com) wrote:

On Thu, Jun 25, 2026 at 11:24 PM [off-list ref] wrote:

quoted

From: Suman Ghosh <redacted>

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 <redacted>
Signed-off-by: Nitin Shetty J <redacted>

---
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.

quoted

---
 .../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.

quoted

+
+       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.

quoted

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