[dpdk-dev,2/7] net/bnxt: fix mtu configuration for the function

Message ID 20170629025142.19404-3-ajit.khaparde@broadcom.com (mailing list archive)
State Changes Requested, archived
Delegated to: Ferruh Yigit
Headers

Checks

Context Check Description
ci/Intel-compilation success Compilation OK
ci/checkpatch success coding style OK

Commit Message

Ajit Khaparde June 29, 2017, 2:51 a.m. UTC
  Set the MTU of the device to MAX size possible.
Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
---
 drivers/net/bnxt/bnxt_hwrm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
  

Comments

Ferruh Yigit June 29, 2017, 10:55 a.m. UTC | #1
On 6/29/2017 3:51 AM, Ajit Khaparde wrote:
> Set the MTU of the device to MAX size possible.

What was the failure with existing code?

> Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>

Can you please add the Fixes tag.

> ---
>  drivers/net/bnxt/bnxt_hwrm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
> index e237041..580b2d8 100644
> --- a/drivers/net/bnxt/bnxt_hwrm.c
> +++ b/drivers/net/bnxt/bnxt_hwrm.c
> @@ -2023,8 +2023,7 @@ static int bnxt_hwrm_pf_func_cfg(struct bnxt *bp, int tx_rings)
>  			HWRM_FUNC_CFG_INPUT_ENABLES_NUM_VNICS |
>  			HWRM_FUNC_CFG_INPUT_ENABLES_NUM_HW_RING_GRPS);
>  	req.flags = rte_cpu_to_le_32(bp->pf.func_cfg_flags);
> -	req.mtu = rte_cpu_to_le_16(bp->eth_dev->data->mtu + ETHER_HDR_LEN +
> -				   ETHER_CRC_LEN + VLAN_TAG_SIZE);
> +	req.mtu = rte_cpu_to_le_16(BNXT_MAX_MTU);

Just question, would this cause larger frames than expected in application?

>  	req.mru = rte_cpu_to_le_16(bp->eth_dev->data->mtu + ETHER_HDR_LEN +
>  				   ETHER_CRC_LEN + VLAN_TAG_SIZE);
>  	req.num_rsscos_ctxs = rte_cpu_to_le_16(bp->max_rsscos_ctx);
>
  
Ajit Khaparde June 30, 2017, 2:27 a.m. UTC | #2
On Thu, Jun 29, 2017 at 5:55 AM, Ferruh Yigit <ferruh.yigit@intel.com>
wrote:

> Just question, would this cause larger frames than expected in application?


No. It just initializes the hardware early. T​he bp->eth_dev->data->mtu
still
controls what goes to the application.
  

Patch

diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index e237041..580b2d8 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -2023,8 +2023,7 @@  static int bnxt_hwrm_pf_func_cfg(struct bnxt *bp, int tx_rings)
 			HWRM_FUNC_CFG_INPUT_ENABLES_NUM_VNICS |
 			HWRM_FUNC_CFG_INPUT_ENABLES_NUM_HW_RING_GRPS);
 	req.flags = rte_cpu_to_le_32(bp->pf.func_cfg_flags);
-	req.mtu = rte_cpu_to_le_16(bp->eth_dev->data->mtu + ETHER_HDR_LEN +
-				   ETHER_CRC_LEN + VLAN_TAG_SIZE);
+	req.mtu = rte_cpu_to_le_16(BNXT_MAX_MTU);
 	req.mru = rte_cpu_to_le_16(bp->eth_dev->data->mtu + ETHER_HDR_LEN +
 				   ETHER_CRC_LEN + VLAN_TAG_SIZE);
 	req.num_rsscos_ctxs = rte_cpu_to_le_16(bp->max_rsscos_ctx);