mbox series

[0/3] segment sanity checks

Message ID 20180910054547.18494-1-david.marchand@6wind.com (mailing list archive)
Headers
Series segment sanity checks |

Message

David Marchand Sept. 10, 2018, 5:45 a.m. UTC 
  Here is a little series which helped me identify a multi segment issue.
Hope it can help others.

The difference since the RFC patches I sent some time ago is that, rather
than force the user to build the dpdk with CONFIG_RTE_LIBRTE_MBUF_DEBUG
enabled, it uses rx/tx callbacks to apply checks on the mbufs.

This is not perfect, since when an invalid mbuf is detected, we try to free
it and a crash is possible at this time (depends on what went wrong).

On the rx side, this is better than let this packet go through the
application and we end up with harder to identify issues.
On the tx side, this is more about validating that the application did not
break the mbuf before passing it to the driver.

Example:
./testpmd -l 2,14 --socket-mem 2048,0 -w 0000:03:00.0 -w 0000:03:00.1 -- -i
[...]
testpmd> port stop all
testpmd> port config all sanity_check rx+tx
testpmd> port config all scatter on
testpmd> port start all
Configuring Port 0 (socket 0)
Port 0: F4:E9:D4:ED:B4:06
Configuring Port 1 (socket 0)
Port 1: F4:E9:D4:ED:B4:07
Checking link statuses...
Done
testpmd> port config mtu 0 9000
testpmd> port config mtu 1 9000
testpmd> start
testpmd: invalid rx mbuf on port 1 queue 0: data length too big in mbuf segment

testpmd> set verbose 1
Change verbose level from 0 to 1
dump mbuf at 0x7f48db9fa740, iova=2291fa7c0, buf_len=2176
  pkt_len=8014, ol_flags=180, nb_segs=4, in_port=1
  segment at 0x7f48db9fa740, data=0x7f48db9fa840, data_len=2112
  segment at 0x7f48db9fb080, data=0x7f48db9fb180, data_len=2112
  segment at 0x7f48db9fb9c0, data=0x7f48db9fbac0, data_len=2112
  segment at 0x7f48db9fc300, data=0x7f48db9fc400, data_len=1678
testpmd: invalid rx mbuf on port 1 queue 0: data length too big in mbuf segment