Hi, Thank you Jijiang for taking the time to get back on this.
On 01/08/2015 11:54 AM, Ananyev, Konstantin wrote: >> And we are able to test all of cases in >> http://dpdk.org/ml/archives/dev/2014-December/009213.html >> >> Test case A: >> >> tx_checksum set sw-tunnel-mode off >> tx_checksum set hw-tunnel-mode off >> tx_checksum set ip hw >> >> test case B.1: >> >> tx_checksum set sw-tunnel-mode on >> tx_checksum set hw-tunnel-mode on >> tx_checksum set ip hw >> tx_checksum set tcp hw >> >> test case B.2: >> >> tx_checksum set sw-tunnel-mode on >> tx_checksum set hw-tunnel-mode off >> tx_checksum set ip hw >> >> test case C: >> >> tx_checksum set sw-tunnel-mode on >> tx_checksum set hw-tunnel-mode on >> tx_checksum set outer-ip hw >> tx_checksum set ip hw >> tx_checksum set tcp hw There is something I don't understand. A forward engine takes any packet in input and output. Packets can be of any kind (eth/arp, eth/ip/tcp, eth/vlan/ip/udp/vxlan/eth/ip/tcp, ...) Today, the behavior of csum forward engine is defined for any kind of packet. See the description and the table in http://dpdk.org/ml/archives/dev/2014-December/009886.html All packets that are not "Ether[/vlan]/(IP|IP6)/(UDP|TCP|SCTP)" or "Ether[/vlan]/(IP|IP6)/UDP/VxLAN/Ether[/vlan]/(IP|IP6)/UDP|TCP|SCTP" are forwarded without beeing modified. In my understanding, the use-case you are describing correspond to specific packet types. So a configuration would work only for one packet format only. Is it correct? I think that the test-pmd command API should define a behavior for the csum forward engine for any packet. What do you think? Regards, Olivier