[net-next PATCH] octeontx2-pf: Check for DMAC extraction before setting VF DMAC

[net-next PATCH] octeontx2-pf: Check for DMAC extraction before setting VF DMAC

[Subbaraya Sundeep]

From: Suman Ghosh <sumang@marvell.com>

Currently while setting a MAC address of a PF's VF (e.g. ip link set
<pf-netdev> vf 0 mac <mac-address>), it simply tries to install a DMAC
based hardware filter. But it is possible that the loaded hardware parser
profile does not support DMAC extraction. Hence check for DMAC extraction
before installing the filter.

Signed-off-by: Suman Ghosh <sumang@marvell.com>
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
---
 .../net/ethernet/marvell/octeontx2/nic/otx2_pf.c   | 31 ++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
index 4e2d120..c8c9cf6 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
@@ -2559,6 +2559,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;
@@ -2572,6 +2574,35 @@ static int otx2_set_vf_mac(struct net_device *netdev, int vf, u8 *mac)
 	if (!is_valid_ether_addr(mac))
 		return -EINVAL;
 
+	/* Check if NPC_DMAC feature is set in NPC. If not set then
+	 * return from the function.
+	 */
+	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;
+	ret = otx2_sync_mbox_msg(&pf->mbox);
+	if (ret) {
+		mutex_unlock(&pf->mbox.lock);
+		return ret;
+	}
+
+	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);
+	}
+
+	mutex_unlock(&pf->mbox.lock);
+
+	if (!rsp->enable)
+		return 0;
+
 	config = &pf->vf_configs[vf];
 	ether_addr_copy(config->mac, mac);
 
-- 
2.7.4

Re: [net-next PATCH] octeontx2-pf: Check for DMAC extraction before setting VF DMAC

[Simon Horman]

On Wed, Jun 25, 2025 at 05:00:02PM +0530, Subbaraya Sundeep wrote:
> From: Suman Ghosh <sumang@marvell.com>
> 
> Currently while setting a MAC address of a PF's VF (e.g. ip link set
> <pf-netdev> vf 0 mac <mac-address>), it simply tries to install a DMAC
> based hardware filter. But it is possible that the loaded hardware parser
> profile does not support DMAC extraction. Hence check for DMAC extraction
> before installing the filter.

Makes sense to me, but should this be treated as a bug fix?

> 
> Signed-off-by: Suman Ghosh <sumang@marvell.com>
> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>

...

Re: [net-next PATCH] octeontx2-pf: Check for DMAC extraction before setting VF DMAC

[Subbaraya Sundeep]

On 2025-06-25 at 19:02:47, Simon Horman (horms@kernel.org) wrote:
> On Wed, Jun 25, 2025 at 05:00:02PM +0530, Subbaraya Sundeep wrote:
> > From: Suman Ghosh <sumang@marvell.com>
> > 
> > Currently while setting a MAC address of a PF's VF (e.g. ip link set
> > <pf-netdev> vf 0 mac <mac-address>), it simply tries to install a DMAC
> > based hardware filter. But it is possible that the loaded hardware parser
> > profile does not support DMAC extraction. Hence check for DMAC extraction
> > before installing the filter.
> 
> Makes sense to me, but should this be treated as a bug fix?
> 
No strong opinion on whether this is a bug fix or not.
We assumed DMAC is required always until on of our customers
came up with profile with no DMAC extraction so that they can
use the additional MCAM space created for other packet fields.
I will send as bug fix if you insist.

Thanks,
Sundeep
> > 
> > Signed-off-by: Suman Ghosh <sumang@marvell.com>
> > Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
> 
> ...

Re: [net-next PATCH] octeontx2-pf: Check for DMAC extraction before setting VF DMAC

[Simon Horman]

On Thu, Jun 26, 2025 at 06:23:30AM +0000, Subbaraya Sundeep wrote:
> On 2025-06-25 at 19:02:47, Simon Horman (horms@kernel.org) wrote:
> > On Wed, Jun 25, 2025 at 05:00:02PM +0530, Subbaraya Sundeep wrote:
> > > From: Suman Ghosh <sumang@marvell.com>
> > > 
> > > Currently while setting a MAC address of a PF's VF (e.g. ip link set
> > > <pf-netdev> vf 0 mac <mac-address>), it simply tries to install a DMAC
> > > based hardware filter. But it is possible that the loaded hardware parser
> > > profile does not support DMAC extraction. Hence check for DMAC extraction
> > > before installing the filter.
> > 
> > Makes sense to me, but should this be treated as a bug fix?
> > 
> No strong opinion on whether this is a bug fix or not.
> We assumed DMAC is required always until on of our customers
> came up with profile with no DMAC extraction so that they can
> use the additional MCAM space created for other packet fields.
> I will send as bug fix if you insist.

No strong feeling on my side either.
Let's leave it for net-next unless someone else thinks otherwise.

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [net-next PATCH] octeontx2-pf: Check for DMAC extraction before setting VF DMAC

[Jakub Kicinski]

On Wed, 25 Jun 2025 17:00:02 +0530 Subbaraya Sundeep wrote:
> +	/* Check if NPC_DMAC feature is set in NPC. If not set then
> +	 * return from the function.
> +	 */
> +	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;
> +	ret = otx2_sync_mbox_msg(&pf->mbox);
> +	if (ret) {
> +		mutex_unlock(&pf->mbox.lock);
> +		return ret;
> +	}
> +
> +	rsp = (struct npc_get_field_status_rsp *)otx2_mbox_get_rsp
> +	       (&pf->mbox.mbox, 0, &req->hdr);

This is too ugly. Cast it to a void pointer to avoid the super long
line.

> +	if (IS_ERR(rsp)) {
> +		mutex_unlock(&pf->mbox.lock);
> +		return PTR_ERR(rsp);
> +	}
> +
> +	mutex_unlock(&pf->mbox.lock);
> +
> +	if (!rsp->enable)
> +		return 0;

Please send as a fix, and factor this out to a helper.
-- 
pw-bot: cr