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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.