From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id DF68B2C50 for ; Thu, 20 Apr 2017 08:12:35 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 23:12:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,224,1488873600"; d="scan'208";a="76598895" Received: from stv-crb-56.sh.intel.com (HELO [10.239.128.116]) ([10.239.128.116]) by orsmga002.jf.intel.com with ESMTP; 19 Apr 2017 23:12:33 -0700 Message-ID: <58F84EC1.3030206@intel.com> Date: Thu, 20 Apr 2017 14:01:37 +0800 From: "Liu, Yong" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Angela Czubak , dts@dpdk.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dts] TestSuite_shutdown_api.py, test_enable_disablejumbo and MTU questions X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 06:12:36 -0000 Czuabk, you're right. Max packet length is not the same concept as MTU. Macro 18 is used for calculate payload length, it included in mac layer and FCS. Some types of NIC like kawela, total length in statistic will not include FCS. So there's some confusing code in the suites. Thanks, Marvin On 04/14/2017 12:08 AM, Angela Czubak wrote: > Ok, partially answering to myself: max-pkt-len is different than MTU, > there is no call to rte_eth_dev_set_mtu when calling "port config all > max-pkt-len". It is truly setting max_rx_pkt_len of > port->dev_conf.rxmode in init_port_config (and then the device is > reconfigured with rte_eth_dev_configure when starting the port). > > This somehow explains, that decreasing by 4 in send_packet might be > connected to the fact that NIC may or may not take FCS into frame length. > > So now I only don't know why HEADER_SIZE['eth'] is 18 (for sure) and > why powerville, springville and kawela_4 are treated differently. > > On 12.04.2017 19:48, Angela Czubak wrote: >> Hi, >> >> >> I was reading TestSuite_shutdown_api.py and have some questions about >> test_enable_disablejumbo. >> >> First of all, what are the expectations when it comes to max-pkt-len? >> I mean, self.dut.send_expect("port config all max-pkt-len %d" % >> jumbo_size, "testpmd> ") (and jumbo_size=2048) calls >> rte_eth_dev_set_mtu. How should this function interpret MTU? It >> believe it is not clearly stated, however for many drivers MTU is >> length of the IP header + its payload. Is there a DPDK convention >> saying otherwise? I mean, in send_packet_method padding is calculated >> subtracting both IP header size and ether header size. I just want to >> know where the border of dropping a packet should lie. >> >> Secondly, why HEADER_SIZE['eth'] is equal 18? Does it take into >> account FCS? Are is there any other reason? And why rx_bytes_exp and >> tx_bytes_exp is decreased by at least 4? (send_packet method). >> >> Last but not least, why for powerville, psringville or kawela_4 >> jumbo_size is increased by 4? This happens as well in >> test_enable_disablejumbo. >> >> Thanks in advance for the response. >> >> >> Regards, >> >> Angela Czubak >> >