[dts] TestSuite_shutdown_api.py, test_enable_disablejumbo and MTU questions

Angela Czubak aczubak at caviumnetworks.com
Thu Apr 13 18:08:38 CEST 2017

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

More information about the dts mailing list