All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Yang, SteveX" <stevex.yang@intel.com>,
	Huisong Li <lihuisong@huawei.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
	"Li, Xiaoyun" <xiaoyun.li@intel.com>,
	"Iremonger, Bernard" <bernard.iremonger@intel.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
	"Yang, Qiming" <qiming.yang@intel.com>,
	"oulijun@huawei.com" <oulijun@huawei.com>,
	"huangdaode@huawei.com" <huangdaode@huawei.com>,
	Lijun Ou <oulijun@huawei.com>
Subject: Re: [dpdk-dev] [PATCH v3 1/3] ethdev: fix MTU doesn't update when jumbo frame disabled
Date: Mon, 25 Jan 2021 12:38:08 +0000	[thread overview]
Message-ID: <ee99d245-73e7-6097-eb79-3926eaa5536d@intel.com> (raw)
In-Reply-To: <DM6PR11MB43628A600BAAEC75FFF1343BF9BD9@DM6PR11MB4362.namprd11.prod.outlook.com>

On 1/25/2021 9:49 AM, Yang, SteveX wrote:
> Hi Huisong,
> 
> Thanks for your review.
> 
> The validity of the pair <DEV_RX_OFFLOAD_JUMBO_FRAME, max_rx_pkt_len> should be 
> checked from application layer (e.g.: testpmd),
> 
> and the RTE layer should keep open enough to adapt the high-layer requirement.
> 
> I’m not sure if exists some applications/NICs that treat ‘packet size < 1500’ as 
> JUMBO_FRAME. If so, that also can work as expect with current code.
> 
> @Yigit, Ferruh <mailto:ferruh.yigit@intel.com>, please correct me if something 
> understand wrong.
> 

Hi Huisong,

Agree that there is a grey area in the API, the question is if 'JUMBO_FRAME' is 
set, can application set the 'max_rx_pkt_len' less than "RTE_ETHER_MTU + 
overhead_len". Lijun (cc'ed) has the same concern.

The API documentation, and checks in the 'rte_eth_dev_configure()' enables 
setting this for a long time, I am reluctant to add this limitation now.
Although agree that application should set 'JUMBO_FRAME' properly based on 
requested 'MTU' value.


> BTW, there perhaps are some confused problems about jumbo frame and 
> max_rx_pkt_len, and Ferruh has scheduled to re-factor this part at release 21.11.
> 
> If you’re interesting about it, please refer to following link: [RFC,v2] doc: 
> announce max Rx packet len field deprecation - Patchwork (dpdk.org) 
> <http://patches.dpdk.org/patch/84522/>
> 
> Thanks & Regards,
> 
> Steve Yang.
> 
> *From:* Huisong Li <lihuisong@huawei.com>
> *Sent:* Monday, January 25, 2021 3:12 PM
> *To:* Yang, SteveX <stevex.yang@intel.com>; dev@dpdk.org
> *Cc:* Lu, Wenzhuo <wenzhuo.lu@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>; 
> Iremonger, Bernard <bernard.iremonger@intel.com>; thomas@monjalon.net; Yigit, 
> Ferruh <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru; Yang, Qiming 
> <qiming.yang@intel.com>; oulijun@huawei.com; huangdaode@huawei.com
> *Subject:* Re: [dpdk-dev] [PATCH v3 1/3] ethdev: fix MTU doesn't update when 
> jumbo frame disabled
> 
> Hi Steve,
> 
> In the current modification, the MTU is updated based on 'max_rx_pkt_len' 
> regardless of whether jumbo frame is enabled.
> 
> Now, MTU is correct when jumbo frmae is disabled. However, when jumbo frame is 
> enabled, the MTU value may be inconsistent with
> 
> the definition of the enabled jumbo frame. Like:
> 
> 1/ DEV_RX_OFFLOAD_JUMBO_FRAME is set;
> 
> 2/ max_rx_pkt_len = 1200
> 
> 3/ dev->data->mtu = 1200 - overhead_len(18) = 1182
> 
> In rte_eth_dev_configure API, the check for 'max_rx_pkt_len' is as follows:
> 
> if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) {  //jumbo frame enabled
>          if (dev_conf->rxmode.max_rx_pkt_len > dev_info.max_rx_pktlen) {
>              xxxx
>              goto rollback;
>          } else if (*dev_conf->rxmode.max_rx_pkt_len < RTE_ETHER_MIN_LEN*) {
>              xxxx
>              goto rollback;
>          }
> } else { //jumbo frame disabled
> 
>          if (pktlen < RTE_ETHER_MIN_MTU + overhead_len ||
>                      pktlen > RTE_ETHER_MTU + overhead_len)
>                          /* Use default value */
>                          dev->data->dev_conf.rxmode.max_rx_pkt_len =
>                                                  RTE_ETHER_MTU + overhead_len;
> 
> }
> 
> Since the applicatin sets DEV_RX_OFFLOAD_JUMBO_FRAME to enable jumbo frame, and 
> the framework API needs to update
> 
> the MTU based on 'max_rx_pkt_len', but the framework API uses 
> *RTE_ETHER_MIN_LEN(64)* to verify the boundary value of
> 
> 'max_rx_pkt_len', instead of "RTE_ETHER_MTU + overhead_len".  As far as I know, 
> if the applicatin sets DEV_RX_OFFLOAD_JUMBO_FRAME
> 
> and 'max_rx_pkt_len' is 1200, the framework API or driver should return a 
> failure. As mentioned in this patch set, the jumbo frame
> 
> offload is set only when 'max_rx_pkt_len' requested is greater than 
> "RTE_ETHER_MTU + eth_overhead" in testpmd.
> 
> I really don't understand it.  How do you understand this behavior?
> 
> Thanks.
> 
> 在 2021/1/22 17:01, Steve Yang 写道:
> 
>     The MTU value should be updated to 'max_rx_pkt_len - overhead'
> 
>     no matter if the JUMBO FRAME offload enabled. If not update this MTU,
> 
>     use will get the wrong MTU info via some command.
> 
>     E.g.: 'show port info all' in testpmd tool.
> 
>     Actually, the 'max_rx_pkt_len' has been used for other purposes in many
> 
>     places now, even though the 'max_rx_pkt_len' is expected 'Only used if
> 
>     JUMBO_FRAME enabled'.
> 
>     For examples,
> 
>     'max_rx_pkt_len' perhaps can be used as the 'rx_ctx.rxmax' in i40e.
> 
>     Fixes: bf0f90d92d30 ("ethdev: fix max Rx packet length check")
> 
>     Signed-off-by: Steve Yang<stevex.yang@intel.com>  <mailto:stevex.yang@intel.com>
> 
>     ---
> 
>       lib/librte_ethdev/rte_ethdev.c | 8 ++++----
> 
>       1 file changed, 4 insertions(+), 4 deletions(-)
> 
>     diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> 
>     index daf5f24f7e..42857e3b67 100644
> 
>     --- a/lib/librte_ethdev/rte_ethdev.c
> 
>     +++ b/lib/librte_ethdev/rte_ethdev.c
> 
>     @@ -1421,10 +1421,6 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
> 
>                              ret = -EINVAL;
> 
>                              goto rollback;
> 
>                      }
> 
>     -
> 
>     -               /* Scale the MTU size to adapt max_rx_pkt_len */
> 
>     -               dev->data->mtu = dev->data->dev_conf.rxmode.max_rx_pkt_len -
> 
>     -                              overhead_len;
> 
>              } else {
> 
>                      uint16_t pktlen = dev_conf->rxmode.max_rx_pkt_len;
> 
>                      if (pktlen < RTE_ETHER_MIN_MTU + overhead_len ||
> 
>     @@ -1434,6 +1430,10 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
> 
>                                                     RTE_ETHER_MTU + overhead_len;
> 
>              }
> 
>       
> 
>     +       /* Scale the MTU size to adapt max_rx_pkt_len */
> 
>     +       dev->data->mtu = dev->data->dev_conf.rxmode.max_rx_pkt_len -
> 
>     +                              overhead_len;
> 
>     +
> 
>              /*
> 
>               * If LRO is enabled, check that the maximum aggregated packet
> 
>               * size is supported by the configured device.
> 


  parent reply	other threads:[~2021-01-25 12:38 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-22  8:13 [dpdk-dev] [PATCH v1] app/testpmd: fix dynamic config error for max-pkt-len Steve Yang
2020-12-23  2:27 ` Li, Xiaoyun
2020-12-23  8:51 ` [dpdk-dev] [PATCH v2] app/testpmd: fix dynamic config error Steve Yang
2020-12-23  9:00   ` Li, Xiaoyun
2021-01-13  8:13   ` Chen, BoX C
2021-01-19 15:44   ` Ferruh Yigit
2021-01-22  9:01   ` [dpdk-dev] [PATCH v3 0/3] fix 'max-pkt-len' errors Steve Yang
2021-01-22  9:01     ` [dpdk-dev] [PATCH v3 1/3] ethdev: fix MTU doesn't update when jumbo frame disabled Steve Yang
2021-01-25  7:12       ` Huisong Li
     [not found]         ` <DM6PR11MB43628A600BAAEC75FFF1343BF9BD9@DM6PR11MB4362.namprd11.prod.outlook.com>
2021-01-25 12:38           ` Ferruh Yigit [this message]
2021-01-22  9:01     ` [dpdk-dev] [PATCH v3 2/3] app/testpmd: fix max-pkt-len option invalid Steve Yang
2021-01-22  9:01     ` [dpdk-dev] [PATCH v3 3/3] app/testpmd: fix dynamic config error Steve Yang
2021-01-22 17:04       ` Ferruh Yigit
2021-01-22 17:15         ` Ferruh Yigit
2021-01-25  8:32     ` [dpdk-dev] [PATCH v4 0/2] fix 'max-pkt-len' errors Steve Yang
2021-01-25  8:32       ` [dpdk-dev] [PATCH v4 1/2] ethdev: fix MTU doesn't update when jumbo frame disabled Steve Yang
2021-01-25 12:41         ` Ferruh Yigit
2021-01-25  8:32       ` [dpdk-dev] [PATCH v4 2/2] app/testpmd: fix max-pkt-len option invalid Steve Yang
2021-01-25 14:45         ` Ferruh Yigit
2021-01-25 15:46         ` Lance Richardson
2021-01-25 17:57           ` Ferruh Yigit
2021-01-25 18:15       ` [dpdk-dev] [PATCH v5] app/testpmd: fix setting maximum packet length Ferruh Yigit
2021-01-25 19:41         ` Lance Richardson
2021-01-26  0:44           ` Ferruh Yigit
2021-01-26  3:22             ` Lance Richardson
2021-01-26  3:45             ` Lance Richardson
2021-01-26  7:54               ` Li, Xiaoyun
2021-01-26 11:01               ` Ferruh Yigit
2021-01-28 21:36                 ` Lance Richardson
2021-01-28 22:12                   ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2021-01-26  9:02         ` [dpdk-dev] " Wisam Monther
2021-01-27  3:04         ` Li, Xiaoyun
2021-01-28  1:57           ` Chen, BoX C
2021-01-28  9:18         ` Wisam Monther
2021-01-28  9:26           ` Ferruh Yigit
2021-01-28 11:08             ` Wisam Monther
2021-01-28 12:07         ` [dpdk-dev] [PATCH v6] " Ferruh Yigit
2021-01-29  9:34           ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ee99d245-73e7-6097-eb79-3926eaa5536d@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bernard.iremonger@intel.com \
    --cc=dev@dpdk.org \
    --cc=huangdaode@huawei.com \
    --cc=lihuisong@huawei.com \
    --cc=oulijun@huawei.com \
    --cc=qiming.yang@intel.com \
    --cc=stevex.yang@intel.com \
    --cc=thomas@monjalon.net \
    --cc=wenzhuo.lu@intel.com \
    --cc=xiaoyun.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.