From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 2199D5F5D for ; Thu, 8 Mar 2018 16:45:12 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2018 07:45:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,441,1515484800"; d="scan'208";a="181024932" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.62]) ([10.237.221.62]) by orsmga004.jf.intel.com with ESMTP; 08 Mar 2018 07:45:08 -0800 To: Shahaf Shuler , Olivier Matz , "dev@dpdk.org" , "Ananyev, Konstantin" , Thomas Monjalon , Bruce Richardson , Andrew Rybchenko References: <20180123135308.tr7nmuqsdeogm7bl@glumotte.dev.6wind.com> From: Ferruh Yigit Message-ID: <717bd36b-a99b-e9f7-2603-f018f61a583f@intel.com> Date: Thu, 8 Mar 2018 15:45:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] questions about new offload ethdev api X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 15:45:13 -0000 On 1/23/2018 2:34 PM, Shahaf Shuler wrote: > Tuesday, January 23, 2018 3:53 PM, Olivier Matz: >> Hi, <...> >> 2/ meaning of rxmode.jumbo_frame, rxmode.enable_scatter, >> rxmode.max_rx_pkt_len >> >> While it's not related to the new API, it is probably a good opportunity to >> clarify the meaning of these flags. I'm not able to find a good documentation >> about them. >> >> Here is my understanding, the configuration only depends on: >> - the maximum rx frame length >> - the amount of data available in a mbuf (minus headroom) >> >> Flags to set in rxmode (example): >> +---------------+----------------+----------------+-----------------+ >> | |mbuf_data_len=1K|mbuf_data_len=2K|mbuf_data_len=16K| >> +---------------+----------------+----------------+-----------------+ >> |max_rx_len=1500|enable_scatter | | | >> +---------------+----------------+----------------+-----------------+ >> |max_rx_len=9000|enable_scatter, |enable_scatter, |jumbo_frame | >> | |jumbo_frame |jumbo_frame | | >> +---------------+----------------+----------------+-----------------+ >> >> If this table is correct, the flag jumbo_frame would be equivalent to check if >> max_rx_pkt_len is above a threshold. >> >> And enable_scatter could be deduced from the mbuf size of the given rxq >> (which is a bit harder but maybe doable). > > I glad you raised this subject. We had a lot of discussion on it internally in Mellanox. > > I fully agree. > All application needs is to specify the maximum packet size it wants to receive. > > I think also the lack of documentation is causing PMDs to use those flags wrongly. For example - some PMDs set the jumbo_frame flag internally without it being set by the application. > > I would like to add one more item : MTU. > What is the relation (if any) between setting MTU and the max_rx_len ? > I know MTU stands for Max Transmit Unit, however at least in Linux it is the same for the Send and the receive. Hi Shahaf, Olivier, Agree to clarify the meaning of these flags. As Shahaf mentioned, I believe one of the confusion is between mtu and max_rx_pkt_len. max_rx_pkt_len and jumbo_frame used is rte_eth_dev_configure() [1] and according comment in rte_ethdev.h max_rx_pkt_len is only valid when jumbo_frame is set [2]. But max_rx_pkt_len is also used in rte_eth_dev_get_mtu(), and for that case there is not jumbo_frame arg passed. And if max_rx_pkt_len > ETHER_MAX_LEN, PMD sets the jumbo_frame itself, as it is the real intention I think that is OK [3]. I am thinking if we can remove max_rx_pkt_len completely and just use MTU? And let PMD set the jumbo_frame based on provided MTU. Also there is max_rx_pktlen field in rte_eth_dev_info [4], which is, as far as I understand, PMD preferred packet len value. At least it needs to be renamed to use same name :) max_rx_pktlen -> max_rx_pkt_len But if max_rx_pkt_len is going, this can also go. For the enable_scatter, I wonder if user wants to have control over here. Even for the jumbo_frame is enabled and mbuf_data_len=2K case, perhaps user don't want to use enable_scatter and prefer packets to be dropped? If so we may want to keep that flag and PMD should behave according what has been provided. [1] rte_ethdev.c, rte_eth_dev_configure(): if jumbo_frame == 1 if rxmode.max_rx_pkt_len > dev_info.max_rx_pktlen return -EINVAL; if rxmode.max_rx_pkt_len < ETHER_MIN_LEN return -EINVAL; else if max_rx_pkt_len < ETHER_MIN_LEN || max_rx_pkt_len > ETHER_MAX_LEN max_rx_pkt_len = ETHER_MAX_LEN [2] rte_ethdev.h, struct rte_eth_rxmode: uint32_t max_rx_pkt_len; /**< Only used if jumbo_frame enabled. */ [3] ixgbe, ixgbe_dev_mtu_set(): frame_size = mtu + ETHER_HDR_LEN + ETHER_CRC_LEN if mtu < ETHER_MIN_MTU) || frame_size > dev_info.max_rx_pktlen return -EINVAL if frame_size > ETHER_MAX_LEN jumbo_frame = 1 else jumbo_frame = 0 max_rx_pkt_len = frame_size i40e, i40e_dev_mtu_set(): frame_size = mtu + I40E_ETH_OVERHEAD if mtu < ETHER_MIN_MTU) || frame_size > I40E_FRAME_SIZE_MAX return -EINVAL if frame_size > ETHER_MAX_LEN jumbo_frame = 1 else jumbo_frame = 0 max_rx_pkt_len = frame_size [4] rte_ethdev.h, struct rte_eth_dev_info: uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */