[PATCH net-next,1/2] devlink: Add new "max_mac_per_vf" generic device param

[PATCH net-next,1/2] devlink: Add new "max_mac_per_vf" generic device param

[mheib]

From: Mohammad Heib <mheib@redhat.com>

Add a new device generic parameter to controls the maximum
number of MAC filters allowed per VF.

For example, to limit the number of mac filter per vf to 3 macs:
 $ devlink dev param set pci/0000:3b:00.0 name max_mac_per_vf \
        value 3 \
        cmode runtime

Signed-off-by: Mohammad Heib <mheib@redhat.com>
---
 Documentation/networking/devlink/devlink-params.rst | 4 ++++
 include/net/devlink.h                               | 4 ++++
 net/devlink/param.c                                 | 5 +++++
 3 files changed, 13 insertions(+)

diff --git a/Documentation/networking/devlink/devlink-params.rst b/Documentation/networking/devlink/devlink-params.rst
index 211b58177e12..4b1f2d994254 100644
--- a/Documentation/networking/devlink/devlink-params.rst
+++ b/Documentation/networking/devlink/devlink-params.rst
@@ -143,3 +143,7 @@ own name.
    * - ``clock_id``
      - u64
      - Clock ID used by the device for registering DPLL devices and pins.
+   * - ``max_mac_per_vf``
+     - u32
+     - Controls the maximum number of MAC address filters a **trusted VF** can
+       use.
diff --git a/include/net/devlink.h b/include/net/devlink.h
index b32c9ceeb81d..dde5dcbca625 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -530,6 +530,7 @@ enum devlink_param_generic_id {
 	DEVLINK_PARAM_GENERIC_ID_EVENT_EQ_SIZE,
 	DEVLINK_PARAM_GENERIC_ID_ENABLE_PHC,
 	DEVLINK_PARAM_GENERIC_ID_CLOCK_ID,
+	DEVLINK_PARAM_GENERIC_ID_MAX_MAC_PER_VF,
 
 	/* add new param generic ids above here*/
 	__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -594,6 +595,9 @@ enum devlink_param_generic_id {
 #define DEVLINK_PARAM_GENERIC_CLOCK_ID_NAME "clock_id"
 #define DEVLINK_PARAM_GENERIC_CLOCK_ID_TYPE DEVLINK_PARAM_TYPE_U64
 
+#define DEVLINK_PARAM_GENERIC_MAX_MAC_PER_VF_NAME "max_mac_per_vf"
+#define DEVLINK_PARAM_GENERIC_MAX_MAC_PER_VF_TYPE DEVLINK_PARAM_TYPE_U32
+
 #define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate)	\
 {									\
 	.id = DEVLINK_PARAM_GENERIC_ID_##_id,				\
diff --git a/net/devlink/param.c b/net/devlink/param.c
index 41dcc86cfd94..62fd789ae01c 100644
--- a/net/devlink/param.c
+++ b/net/devlink/param.c
@@ -102,6 +102,11 @@ static const struct devlink_param devlink_param_generic[] = {
 		.name = DEVLINK_PARAM_GENERIC_CLOCK_ID_NAME,
 		.type = DEVLINK_PARAM_GENERIC_CLOCK_ID_TYPE,
 	},
+	{
+		.id = DEVLINK_PARAM_GENERIC_ID_MAX_MAC_PER_VF,
+		.name = DEVLINK_PARAM_GENERIC_MAX_MAC_PER_VF_NAME,
+		.type = DEVLINK_PARAM_GENERIC_MAX_MAC_PER_VF_TYPE,
+	},
 };
 
 static int devlink_param_generic_verify(const struct devlink_param *param)
-- 
2.50.1

[PATCH net-next,2/2] i40e: support generic devlink param "max_mac_per_vf"

[mheib]

From: Mohammad Heib <mheib@redhat.com>

Add support for the new generic devlink runtime parameter
"max_mac_per_vf", which controls the maximum number of MAC addresses
a trusted VF can use.

By default (value 0), the driver enforces its internally calculated
per-VF MAC filter limit. A non-zero value acts as a strict cap,
overriding the internal calculation.

Please note that the configured value is only a theoretical maximum
and a hardware limits may still apply.

- Previous discussion about this change:
  https://lore.kernel.org/netdev/20250805134042.2604897-1-dhill@redhat.com
  https://lore.kernel.org/netdev/20250823094952.182181-1-mheib@redhat.com

Signed-off-by: Mohammad Heib <mheib@redhat.com>
---
 Documentation/networking/devlink/i40e.rst     | 35 ++++++++++++++
 drivers/net/ethernet/intel/i40e/i40e.h        |  4 ++
 .../net/ethernet/intel/i40e/i40e_devlink.c    | 48 ++++++++++++++++++-
 .../ethernet/intel/i40e/i40e_virtchnl_pf.c    | 28 +++++++----
 4 files changed, 103 insertions(+), 12 deletions(-)

diff --git a/Documentation/networking/devlink/i40e.rst b/Documentation/networking/devlink/i40e.rst
index d3cb5bb5197e..3052f638fdd5 100644
--- a/Documentation/networking/devlink/i40e.rst
+++ b/Documentation/networking/devlink/i40e.rst
@@ -7,6 +7,41 @@ i40e devlink support
 This document describes the devlink features implemented by the ``i40e``
 device driver.
 
+Parameters
+==========
+
+.. list-table:: Generic parameters implemented
+    :widths: 5 5 90
+
+    * - Name
+      - Mode
+      - Notes
+    * - ``max_mac_per_vf``
+      - runtime
+      - Controls the maximum number of MAC addresses a **trusted VF** can use
+        on i40e devices.
+
+        By default (``0``), the driver enforces its internally calculated per-VF
+        MAC filter limit, which is based on the number of allocated VFS.
+
+        If set to a non-zero value, this parameter acts as a strict cap:
+        the driver will use the user-provided value instead of its internal
+        calculation.
+
+        **Important notes:**
+        - MAC filters are a **shared hardware resource** across all VFs.
+          Setting a high value may cause other VFs to be starved of filters.
+
+        - This value is a **theoretical maximum**. The hardware may return
+          errors when its absolute limit is reached, regardless of the value
+          set here.
+
+        - Only **trusted VFs** are affected; untrusted VFs use a fixed small
+          limit.
+
+        The default value is ``0`` (internal calculation is used).
+
+
 Info versions
 =============
 
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index 801a57a925da..d2d03db2acec 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -574,6 +574,10 @@ struct i40e_pf {
 	struct i40e_vf *vf;
 	int num_alloc_vfs;	/* actual number of VFs allocated */
 	u32 vf_aq_requests;
+	/* If set to non-zero, the device uses this value
+	 * as maximum number of MAC filters per VF.
+	 */
+	u32 max_mac_per_vf;
 	u32 arq_overflows;	/* Not fatal, possibly indicative of problems */
 	struct ratelimit_state mdd_message_rate_limit;
 	/* DCBx/DCBNL capability for PF that indicates
diff --git a/drivers/net/ethernet/intel/i40e/i40e_devlink.c b/drivers/net/ethernet/intel/i40e/i40e_devlink.c
index cc4e9e2addb7..cd01e35da94e 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_devlink.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_devlink.c
@@ -5,6 +5,35 @@
 #include "i40e.h"
 #include "i40e_devlink.h"
 
+static int i40e_max_mac_per_vf_set(struct devlink *devlink,
+				   u32 id,
+				   struct devlink_param_gset_ctx *ctx,
+				   struct netlink_ext_ack *extack)
+{
+	struct i40e_pf *pf = devlink_priv(devlink);
+
+	pf->max_mac_per_vf = ctx->val.vu32;
+	return 0;
+}
+
+static int i40e_max_mac_per_vf_get(struct devlink *devlink,
+				   u32 id,
+				   struct devlink_param_gset_ctx *ctx)
+{
+	struct i40e_pf *pf = devlink_priv(devlink);
+
+	ctx->val.vu32 = pf->max_mac_per_vf;
+	return 0;
+}
+
+static const struct devlink_param i40e_dl_params[] = {
+	DEVLINK_PARAM_GENERIC(MAX_MAC_PER_VF,
+			      BIT(DEVLINK_PARAM_CMODE_RUNTIME),
+			      i40e_max_mac_per_vf_get,
+			      i40e_max_mac_per_vf_set,
+			      NULL),
+};
+
 static void i40e_info_get_dsn(struct i40e_pf *pf, char *buf, size_t len)
 {
 	u8 dsn[8];
@@ -165,7 +194,18 @@ void i40e_free_pf(struct i40e_pf *pf)
  **/
 void i40e_devlink_register(struct i40e_pf *pf)
 {
-	devlink_register(priv_to_devlink(pf));
+	struct devlink *dl = priv_to_devlink(pf);
+	struct device *dev = &pf->pdev->dev;
+	int err;
+
+	err = devlink_params_register(dl, i40e_dl_params,
+				      ARRAY_SIZE(i40e_dl_params));
+	if (err)
+		dev_err(dev,
+			"devlink params register failed with error %d", err);
+
+	devlink_register(dl);
+
 }
 
 /**
@@ -176,7 +216,11 @@ void i40e_devlink_register(struct i40e_pf *pf)
  **/
 void i40e_devlink_unregister(struct i40e_pf *pf)
 {
-	devlink_unregister(priv_to_devlink(pf));
+	struct devlink *dl = priv_to_devlink(pf);
+
+	devlink_unregister(dl);
+	devlink_params_unregister(dl, i40e_dl_params,
+				  ARRAY_SIZE(i40e_dl_params));
 }
 
 /**
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 081a4526a2f0..e6d90d51221b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -2935,19 +2935,26 @@ static inline int i40e_check_vf_permission(struct i40e_vf *vf,
 		if (!f)
 			++mac_add_cnt;
 	}
-
-	/* If this VF is not privileged, then we can't add more than a limited
-	 * number of addresses.
+	/* Determine the maximum number of MAC addresses this VF may use.
+	 *
+	 * - For untrusted VFs: use a fixed small limit.
+	 *
+	 * - For trusted VFs: limit is calculated by dividing total MAC
+	 *  filter pool across all VFs/ports.
 	 *
-	 * If this VF is trusted, it can use more resources than untrusted.
-	 * However to ensure that every trusted VF has appropriate number of
-	 * resources, divide whole pool of resources per port and then across
-	 * all VFs.
+	 * - User can override this by devlink param "max_mac_per_vf".
+	 *   If set its value is used as a strict cap.
+	 *   Note:
+	 *    even when overridden, this is a theoretical maximum; hardware
+	 *    may reject additional MACs if the absolute HW limit is reached.
 	 */
-	if (!vf_trusted)
+	if (!vf_trusted) {
 		mac_add_max = I40E_VC_MAX_MAC_ADDR_PER_VF;
-	else
+	} else {
 		mac_add_max = I40E_VC_MAX_MACVLAN_PER_TRUSTED_VF(pf->num_alloc_vfs, hw->num_ports);
+		if (pf->max_mac_per_vf > 0)
+			mac_add_max = pf->max_mac_per_vf;
+	}
 
 	/* VF can replace all its filters in one step, in this case mac_add_max
 	 * will be added as active and another mac_add_max will be in
@@ -2961,7 +2968,8 @@ static inline int i40e_check_vf_permission(struct i40e_vf *vf,
 			return -EPERM;
 		} else {
 			dev_err(&pf->pdev->dev,
-				"Cannot add more MAC addresses, trusted VF exhausted it's resources\n");
+				"Cannot add more MAC addresses: trusted VF reached its maximum allowed limit (%d)\n",
+				mac_add_max);
 			return -EPERM;
 		}
 	}
-- 
2.50.1

RE: [PATCH net-next,2/2] i40e: support generic devlink param "max_mac_per_vf"

[Loktionov, Aleksandr]

> -----Original Message-----
> From: mheib@redhat.com <mheib@redhat.com>
> Sent: Wednesday, September 3, 2025 9:58 AM
> To: intel-wired-lan@lists.osuosl.org
> Cc: przemyslawx.patynowski@intel.com; jiri@resnulli.us;
> netdev@vger.kernel.org; horms@kernel.org; Keller, Jacob E
> <jacob.e.keller@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Mohammad Heib <mheib@redhat.com>
> Subject: [PATCH net-next,2/2] i40e: support generic devlink param
> "max_mac_per_vf"
> 
> From: Mohammad Heib <mheib@redhat.com>
> 
> Add support for the new generic devlink runtime parameter
> "max_mac_per_vf", which controls the maximum number of MAC addresses a
> trusted VF can use.


Good day Mohammad,

Thanks for working on this and for the clear explanation in the commit message.

I have a couple of questions and thoughts:

1) Scope of the parameter
    The name max_mac_per_vf is a bit ambiguous. From the description,
    it seems to apply only to trusted VFs, but the name does not make that obvious.
    Would it make sense to either:
	- Make the name reflect that (e.g., max_mac_per_trusted_vf), or
	- Introduce two separate parameters for trusted and untrusted VFs if both cases need to be handled differently?

2)Problem statement
    It would help to better understand the underlying problem this parameter is solving.
    Is the goal to enforce a global cap for all VFs, or to provide operators with a way
    to fine-tune per-VF limits? From my perspective, the most important part is
    clearly stating the problem and the use case.

3)Granularity
    If the intent is to give operators flexibility, a single global parameter might not be enough.
    For example, limiting the number of MAC filters per specific VF (or having different limits for trusted vs. untrusted)
    could be a real-world requirement. This patch doesn't seem to address that scenario.

Could you share more details about the use case and whether per-VF granularity was considered?

Thanks again for the work on this. Looking forward to your thoughts.

Best regards,
Aleksandr

> 
> By default (value 0), the driver enforces its internally calculated
> per-VF MAC filter limit. A non-zero value acts as a strict cap,
> overriding the internal calculation.
> 
> Please note that the configured value is only a theoretical maximum
> and a hardware limits may still apply.
> 
> - Previous discussion about this change:
>   https://lore.kernel.org/netdev/20250805134042.2604897-1-
> dhill@redhat.com
>   https://lore.kernel.org/netdev/20250823094952.182181-1-
> mheib@redhat.com
> 
> Signed-off-by: Mohammad Heib <mheib@redhat.com>
> ---

...

> --
> 2.50.1

Re: [PATCH net-next,2/2] i40e: support generic devlink param "max_mac_per_vf"

[mohammad heib]

Hello Aleksandr,

Thank you for your review.

On 9/3/25 12:07 PM, Loktionov, Aleksandr wrote:
> 
> 
>> -----Original Message-----
>> From: mheib@redhat.com <mheib@redhat.com>
>> Sent: Wednesday, September 3, 2025 9:58 AM
>> To: intel-wired-lan@lists.osuosl.org
>> Cc: przemyslawx.patynowski@intel.com; jiri@resnulli.us;
>> netdev@vger.kernel.org; horms@kernel.org; Keller, Jacob E
>> <jacob.e.keller@intel.com>; Loktionov, Aleksandr
>> <aleksandr.loktionov@intel.com>; Nguyen, Anthony L
>> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
>> <przemyslaw.kitszel@intel.com>; Mohammad Heib <mheib@redhat.com>
>> Subject: [PATCH net-next,2/2] i40e: support generic devlink param
>> "max_mac_per_vf"
>>
>> From: Mohammad Heib <mheib@redhat.com>
>>
>> Add support for the new generic devlink runtime parameter
>> "max_mac_per_vf", which controls the maximum number of MAC addresses a
>> trusted VF can use.
> 
> 
> Good day Mohammad,
> 
> Thanks for working on this and for the clear explanation in the commit message.
> 
> I have a couple of questions and thoughts:
> 
> 1) Scope of the parameter
>      The name max_mac_per_vf is a bit ambiguous. From the description,
>      it seems to apply only to trusted VFs, but the name does not make that obvious.
>      Would it make sense to either:
> 	- Make the name reflect that (e.g., max_mac_per_trusted_vf), or
> 	- Introduce two separate parameters for trusted and untrusted VFs if both cases need to be handled differently?
I agree that the name could be a bit confusing. Since this is a generic 
devlink parameter, different devices may handle trusted and untrusted 
VFs differently.
For i40e specifically, the device does treat trusted VFs differently 
from untrusted ones, and this is documented in devlink/i40e.rst.
However, I chose a more general name to avoid creating a separate 
devlink parameter for untrusted VFs, which likely wouldn’t be used.
On reflection, I should update the patch number 1 to remove the 
**trusted VF** wording from the description to avoid implying that the 
parameter only applies to trusted VFs.
> 
> 2)Problem statement
>      It would help to better understand the underlying problem this parameter is solving.
>      Is the goal to enforce a global cap for all VFs, or to provide operators with a way
>      to fine-tune per-VF limits? From my perspective, the most important part is
>      clearly stating the problem and the use case.
> 
My main goal here is to enforce a global cap for all VFs.
There was a long discussion [1] about this, and one of the ideas raised 
was to create fine-tuned per-VF limits using devlink resources instead 
of a parameter
However, currently in i40e, we only create a devlink port per PF and no 
devlink ports per VF.
Implementing the resource-per-VF approach would therefore require some 
extra work.
so i decided to go with this global cap for now.
[1] - 
https://patchwork.kernel.org/project/netdevbpf/patch/20250805134042.2604897-2-dhill@redhat.com/
> 3)Granularity
>      If the intent is to give operators flexibility, a single global parameter might not be enough.
>      For example, limiting the number of MAC filters per specific VF (or having different limits for trusted vs. untrusted)
>      could be a real-world requirement. This patch doesn't seem to address that scenario.
> 
> Could you share more details about the use case and whether per-VF granularity was considered?
> 
> Thanks again for the work on this. Looking forward to your thoughts.
> 
> Best regards,
> Aleksandr
> 
please see - 
https://patchwork.kernel.org/project/netdevbpf/patch/20250805134042.2604897-2-dhill@redhat.com/
>>
>> By default (value 0), the driver enforces its internally calculated
>> per-VF MAC filter limit. A non-zero value acts as a strict cap,
>> overriding the internal calculation.
>>
>> Please note that the configured value is only a theoretical maximum
>> and a hardware limits may still apply.
>>
>> - Previous discussion about this change:
>>    https://lore.kernel.org/netdev/20250805134042.2604897-1-
>> dhill@redhat.com
>>    https://lore.kernel.org/netdev/20250823094952.182181-1-
>> mheib@redhat.com
>>
>> Signed-off-by: Mohammad Heib <mheib@redhat.com>
>> ---
> 
> ...
> 
>> --
>> 2.50.1
> 
  Thank you,

Re: [PATCH net-next,2/2] i40e: support generic devlink param "max_mac_per_vf"

[mohammad heib]

Hi Aleksandr,

Thanks again for your review.
I’ve updated the documentation and commit message in v2 to address your 
feedback.

Appreciate your time!
On 9/3/25 3:35 PM, Loktionov, Aleksandr wrote:
> *From:*mohammad heib <mheib@redhat.com>
> *Sent:* Wednesday, September 3, 2025 12:01 PM
> *To:* Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; intel-wired- 
> lan@lists.osuosl.org
> *Cc:* przemyslawx.patynowski@intel.com; jiri@resnulli.us; 
> netdev@vger.kernel.org; horms@kernel.org; Keller, Jacob E 
> <jacob.e.keller@intel.com>; Nguyen, Anthony L 
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw 
> <przemyslaw.kitszel@intel.com>
> *Subject:* Re: [PATCH net-next,2/2] i40e: support generic devlink param 
> "max_mac_per_vf"
> 
> Hello Aleksandr,
> 
> Thank you for your review.
> 
> On 9/3/25 12:07 PM, Loktionov, Aleksandr wrote:
> 
>         -----Original Message-----
> 
>         From:mheib@redhat.com <mailto:mheib@redhat.com> <mheib@redhat.com> <mailto:mheib@redhat.com>
> 
>         Sent: Wednesday, September 3, 2025 9:58 AM
> 
>         To:intel-wired-lan@lists.osuosl.org <mailto:intel-wired-lan@lists.osuosl.org>
> 
>         Cc:przemyslawx.patynowski@intel.com <mailto:przemyslawx.patynowski@intel.com>;jiri@resnulli.us <mailto:jiri@resnulli.us>;
> 
>         netdev@vger.kernel.org <mailto:netdev@vger.kernel.org>;horms@kernel.org <mailto:horms@kernel.org>; Keller, Jacob E
> 
>         <jacob.e.keller@intel.com> <mailto:jacob.e.keller@intel.com>; Loktionov, Aleksandr
> 
>         <aleksandr.loktionov@intel.com> <mailto:aleksandr.loktionov@intel.com>; Nguyen, Anthony L
> 
>         <anthony.l.nguyen@intel.com> <mailto:anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> 
>         <przemyslaw.kitszel@intel.com> <mailto:przemyslaw.kitszel@intel.com>; Mohammad Heib<mheib@redhat.com> <mailto:mheib@redhat.com>
> 
>         Subject: [PATCH net-next,2/2] i40e: support generic devlink param
> 
>         "max_mac_per_vf"
> 
>         From: Mohammad Heib<mheib@redhat.com> <mailto:mheib@redhat.com>
> 
>         Add support for the new generic devlink runtime parameter
> 
>         "max_mac_per_vf", which controls the maximum number of MAC addresses a
> 
>         trusted VF can use.
> 
>     Good day Mohammad,
> 
>     Thanks for working on this and for the clear explanation in the commit message.
> 
>     I have a couple of questions and thoughts:
> 
>     1) Scope of the parameter
> 
>          The name max_mac_per_vf is a bit ambiguous. From the description,
> 
>          it seems to apply only to trusted VFs, but the name does not make that obvious.
> 
>          Would it make sense to either:
> 
>       - Make the name reflect that (e.g., max_mac_per_trusted_vf), or
> 
>       - Introduce two separate parameters for trusted and untrusted VFs if both cases need to be handled differently?
> 
> I agree that the name could be a bit confusing. Since this is a generic 
> devlink parameter, different devices may handle trusted and untrusted 
> VFs differently.
> For i40e specifically, the device does treat trusted VFs differently 
> from untrusted ones, and this is documented in devlink/i40e.rst.
> However, I chose a more general name to avoid creating a separate 
> devlink parameter for untrusted VFs, which likely wouldn’t be used.
> On reflection, I should update the patch number 1 to remove the 
> **trusted VF** wording from the description to avoid implying that the 
> parameter only applies to trusted VFs.
> 
>     I believe the community generally aims for solutions that work
>     consistently across different hardware. If this parameter behaves
>     differently on i40e compared to mlx5 (or other drivers), it might be
>     helpful to mention that explicitly in the documentation or commit
>     message.
> 
>     2)Problem statement
> 
>          It would help to better understand the underlying problem this parameter is solving.
> 
>          Is the goal to enforce a global cap for all VFs, or to provide operators with a way
> 
>          to fine-tune per-VF limits? From my perspective, the most important part is
> 
>          clearly stating the problem and the use case.
> 
> My main goal here is to enforce a global cap for all VFs.
> There was a long discussion [1] about this, and one of the ideas raised 
> was to create fine-tuned per-VF limits using devlink resources instead 
> of a parameter
> However, currently in i40e, we only create a devlink port per PF and no 
> devlink ports per VF.
> Implementing the resource-per-VF approach would therefore require some 
> extra work.
> so i decided to go with this global cap for now.
> [1] - https://patchwork.kernel.org/project/netdevbpf/ 
> patch/20250805134042.2604897-2-dhill@redhat.com/ <https:// 
> patchwork.kernel.org/project/netdevbpf/patch/20250805134042.2604897-2- 
> dhill@redhat.com/>
> 
> Thank, you Mohammad
> 
> The https://patchwork.kernel.org/project/netdevbpf/ 
> patch/20250805134042.2604897-2-dhill@redhat.com/ <https:// 
> patchwork.kernel.org/project/netdevbpf/patch/20250805134042.2604897-2- 
> dhill@redhat.com/> explains many things.
> 
> It might be helpful to include a brief description of the problem being 
> solved directly in the commit message. This gives reviewers the 
> necessary context and makes it easier to understand the motivation 
> behind the change.
> 
>     …
>