From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [dpdk-dev] [Bug 290] RX packets in Virtio are corrupted in case of split to several mbufs
Date: Sun, 02 Jun 2019 11:45:20 +0000 [thread overview]
Message-ID: <bug-290-3@http.bugs.dpdk.org/> (raw)
https://bugs.dpdk.org/show_bug.cgi?id=290
Bug ID: 290
Summary: RX packets in Virtio are corrupted in case of split to
several mbufs
Product: DPDK
Version: 19.05
Hardware: All
OS: All
Status: CONFIRMED
Severity: normal
Priority: Normal
Component: vhost/virtio
Assignee: dev@dpdk.org
Reporter: ybrustin@cisco.com
CC: gavin.hu@arm.com, maxime.coquelin@redhat.com
Target Milestone: ---
Hi,
Starting from this commit - bcac5aa207f896c46963b2ac0a06bc09b1e912a5, RX
packets that are split to several mbufs are corrupted.
For example, we are using 2KB mbufs, and sending Jumbo packets (~9k).
After several received packets we got bad packet:
RX pkt #1
dump mbuf at 0x1f5082300, iova=266c82380, buf_len=2112
pkt_len=9230, ol_flags=0, nb_segs=5, in_port=0
segment at 0x1f5082300, data=0x1f50823c0, data_len=2048
Dump data at [0x1f50823c0], len=16
00000000: 16 58 82 41 3C CF E2 D1 D5 84 5A 99 08 00 45 00 | .X.A<.....Z...E.
segment at 0x1f50819c0, data=0x1f5081a74, data_len=2060
segment at 0x1f5081080, data=0x1f5081134, data_len=2060
segment at 0x1f5080740, data=0x1f50807f4, data_len=2060
segment at 0x1f507fe00, data=0x1f507feb4, data_len=1002
RX pkt #2
dump mbuf at 0x1f507f4c0, iova=266c7f540, buf_len=2112
pkt_len=9230, ol_flags=0, nb_segs=5, in_port=0
segment at 0x1f507f4c0, data=0x1f507f580, data_len=2048
Dump data at [0x1f507f580], len=16
00000000: 16 58 82 41 3C CF E2 D1 D5 84 5A 99 08 00 45 00 | .X.A<.....Z...E.
segment at 0x1f507eb80, data=0x1f507ec34, data_len=2060
segment at 0x1f506fb00, data=0x1f506fbb4, data_len=2060
segment at 0x1f5095440, data=0x1f50954f4, data_len=2060
segment at 0x1f5094b00, data=0x1f5094bb4, data_len=1002
RX pkt #3
dump mbuf at 0x1f507c680, iova=266c7c700, buf_len=2112
pkt_len=9230, ol_flags=0, nb_segs=5, in_port=0
segment at 0x1f507c680, data=0x1f507c740, data_len=2048
Dump data at [0x1f507c740], len=16
00000000: 16 58 82 41 3C CF E2 D1 D5 84 5A 99 08 00 45 00 | .X.A<.....Z...E.
segment at 0x1f507bd40, data=0x1f507bdf4, data_len=2060
segment at 0x1f507b400, data=0x1f507b4b4, data_len=2060
segment at 0x1f507aac0, data=0x1f507ab74, data_len=2060
segment at 0x1f507a180, data=0x1f507a234, data_len=1002
RX pkt #4
dump mbuf at 0x1f5079840, iova=266c798c0, buf_len=2112
pkt_len=9230, ol_flags=0, nb_segs=5, in_port=0
segment at 0x1f5079840, data=0x1f5079900, data_len=2048
Dump data at [0x1f5079900], len=16
00000000: 16 58 82 41 3C CF E2 D1 D5 84 5A 99 08 00 45 00 | .X.A<.....Z...E.
segment at 0x1f5078f00, data=0x1f5078fb4, data_len=2060
segment at 0x1f50785c0, data=0x1f5078674, data_len=2060
segment at 0x1f5077c80, data=0x1f5077d34, data_len=2060
segment at 0x1f5077340, data=0x1f50773f4, data_len=1002
RX pkt #5
dump mbuf at 0x1f5076a00, iova=266c76a80, buf_len=2112
pkt_len=9230, ol_flags=0, nb_segs=5, in_port=0
segment at 0x1f5076a00, data=0x1f5076ac0, data_len=2048
Dump data at [0x1f5076ac0], len=16
00000000: 16 58 82 41 3C CF E2 D1 D5 84 5A 99 08 00 45 00 | .X.A<.....Z...E.
segment at 0x1f50760c0, data=0x1f5076174, data_len=2060
segment at 0x1f5075780, data=0x1f5075834, data_len=2060
segment at 0x1f5074e40, data=0x1f5074ef4, data_len=2060
segment at 0x1f5074500, data=0x1f50745b4, data_len=1002
RX pkt #6
dump mbuf at 0x1f5073bc0, iova=266c73c40, buf_len=2112
pkt_len=9230, ol_flags=0, nb_segs=5, in_port=0
segment at 0x1f5073bc0, data=0x1f5073c80, data_len=2048
Dump data at [0x1f5073c80], len=16
00000000: 16 58 82 41 3C CF E2 D1 D5 84 5A 99 08 00 45 00 | .X.A<.....Z...E.
segment at 0x1f5073280, data=0x1f5073334, data_len=2060
segment at 0x1f5072940, data=0x1f50729f4, data_len=2060
segment at 0x1f5072000, data=0x1f50720b4, data_len=2060
segment at 0x1f50716c0, data=0x1f5071774, data_len=1002
RX pkt #7
dump mbuf at 0x1f5070d80, iova=266c70e00, buf_len=2112
pkt_len=9230, ol_flags=0, nb_segs=5, in_port=0
segment at 0x1f5070d80, data=0x1f5070e40, data_len=2048
Dump data at [0x1f5070e40], len=16
00000000: 16 58 82 41 3C CF E2 D1 D5 84 5A 99 08 00 45 00 | .X.A<.....Z...E.
segment at 0x1f5070440, data=0x1f50704f4, data_len=2060
total packets length is not valid: pkt_len: 9230, sum of data_len: 4108
#seg is not valid, written in mbuf: 5, actual count: 2
As a workaround, we will use 9KB mbufs for now...
Thanks,
Yaroslav.
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2019-06-02 11:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-290-3@http.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).