dev.dpdk.org archive mirror
 help / color / mirror / Atom feed
* [dpdk-dev] [Bug 290] RX packets in Virtio are corrupted in case of split to several mbufs
@ 2019-06-02 11:45 bugzilla
  0 siblings, 0 replies; only message in thread
From: bugzilla @ 2019-06-02 11:45 UTC (permalink / raw)
  To: dev

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.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2019-06-02 11:45 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-02 11:45 [dpdk-dev] [Bug 290] RX packets in Virtio are corrupted in case of split to several mbufs bugzilla

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).