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

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

[nshettyj]

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>
---
 .../ethernet/marvell/octeontx2/nic/otx2_pf.c  | 34 +++++++++++++++++++
 1 file changed, 34 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..8e4435d9e520 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
@@ -2546,6 +2546,8 @@ static int otx2_do_set_vf_mac(struct otx2_nic *pf, int vf, const u8 *mac)
 static int otx2_set_vf_mac(struct net_device *netdev, int vf, u8 *mac)
 {
 	struct otx2_nic *pf = netdev_priv(netdev);
+	struct npc_get_field_status_req *req;
+	struct npc_get_field_status_rsp *rsp;
 	struct pci_dev *pdev = pf->pdev;
 	struct otx2_vf_config *config;
 	int ret;
@@ -2559,6 +2561,38 @@ static int otx2_set_vf_mac(struct net_device *netdev, int vf, u8 *mac)
 	if (!is_valid_ether_addr(mac))
 		return -EINVAL;
 
+	/* Skip installing the DMAC filter if the hardware parser profile
+	 * does not support DMAC extraction.
+	 */
+	mutex_lock(&pf->mbox.lock);
+	req = otx2_mbox_alloc_msg_npc_get_field_status(&pf->mbox);
+	if (!req) {
+		mutex_unlock(&pf->mbox.lock);
+		return -ENOMEM;
+	}
+
+	req->field = NPC_DMAC;
+	if (otx2_sync_mbox_msg(&pf->mbox)) {
+		mutex_unlock(&pf->mbox.lock);
+		return -EINVAL;
+	}
+
+	rsp = (struct npc_get_field_status_rsp *)otx2_mbox_get_rsp
+	       (&pf->mbox.mbox, 0, &req->hdr);
+	if (IS_ERR(rsp)) {
+		mutex_unlock(&pf->mbox.lock);
+		return PTR_ERR(rsp);
+	}
+
+	if (!rsp->enable) {
+		mutex_unlock(&pf->mbox.lock);
+		netdev_warn(netdev, "VF %d MAC filter not installed: DMAC extraction not supported by parser profile\n",
+			    vf);
+		return 0;
+	}
+
+	mutex_unlock(&pf->mbox.lock);
+
 	config = &pf->vf_configs[vf];
 	ether_addr_copy(config->mac, mac);
 
-- 
2.48.1

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

[Harshitha Ramamurthy]

On Thu, Jun 25, 2026 at 10:30 AM <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>
> ---
>  .../ethernet/marvell/octeontx2/nic/otx2_pf.c  | 34 +++++++++++++++++++
>  1 file changed, 34 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..8e4435d9e520 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> @@ -2546,6 +2546,8 @@ static int otx2_do_set_vf_mac(struct otx2_nic *pf, int vf, const u8 *mac)
>  static int otx2_set_vf_mac(struct net_device *netdev, int vf, u8 *mac)
>  {
>         struct otx2_nic *pf = netdev_priv(netdev);
> +       struct npc_get_field_status_req *req;
> +       struct npc_get_field_status_rsp *rsp;
>         struct pci_dev *pdev = pf->pdev;
>         struct otx2_vf_config *config;
>         int ret;
> @@ -2559,6 +2561,38 @@ static int otx2_set_vf_mac(struct net_device *netdev, int vf, u8 *mac)
>         if (!is_valid_ether_addr(mac))
>                 return -EINVAL;
>
> +       /* Skip installing the DMAC filter if the hardware parser profile
> +        * does not support DMAC extraction.
> +        */
> +       mutex_lock(&pf->mbox.lock);
> +       req = otx2_mbox_alloc_msg_npc_get_field_status(&pf->mbox);
> +       if (!req) {
> +               mutex_unlock(&pf->mbox.lock);
> +               return -ENOMEM;
> +       }
> +
> +       req->field = NPC_DMAC;
> +       if (otx2_sync_mbox_msg(&pf->mbox)) {
> +               mutex_unlock(&pf->mbox.lock);
> +               return -EINVAL;
> +       }
> +
> +       rsp = (struct npc_get_field_status_rsp *)otx2_mbox_get_rsp
> +              (&pf->mbox.mbox, 0, &req->hdr);
> +       if (IS_ERR(rsp)) {
> +               mutex_unlock(&pf->mbox.lock);
> +               return PTR_ERR(rsp);
> +       }
> +
> +       if (!rsp->enable) {
> +               mutex_unlock(&pf->mbox.lock);
> +               netdev_warn(netdev, "VF %d MAC filter not installed: DMAC extraction not supported by parser profile\n",
> +                           vf);
> +               return 0;

Is the intent to return success here even though the MAC address was
not programmed?

> +       }
> +
> +       mutex_unlock(&pf->mbox.lock);
> +

Why not move all these checks into the otx2_do_set_vf_mac() since that
anyway acquires the pf->mbox.lock? That way you could also fold all
the mutex_unlock() calls introduced in the error paths in this patch
into the existing goto-out in that function.

>         config = &pf->vf_configs[vf];
>         ether_addr_copy(config->mac, mac);
>
> --
> 2.48.1
>
>

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

[nshettyj]

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.
---
 .../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;
+	}
+
+	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);
+		err = -EOPNOTSUPP;
+		goto out;
+	}
+
 	req = otx2_mbox_alloc_msg_npc_install_flow(&pf->mbox);
 	if (!req) {
 		err = -ENOMEM;
-- 
2.48.1

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

[Harshitha Ramamurthy]

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

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

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

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

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

[Nitin Shetty J]

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