DPDK usage discussions
 help / color / mirror / Atom feed
* Corrupted payload when sending many individual mbufs in loop
@ 2025-02-04 22:36 Alan Beadle
  2025-02-04 23:26 ` Stephen Hemminger
  0 siblings, 1 reply; 4+ messages in thread
From: Alan Beadle @ 2025-02-04 22:36 UTC (permalink / raw)
  To: users

Hello,

I am working on an application that involves fragmenting a large
buffer into many smaller packets/mbufs and sending them with DPDK. The
fragment packets for each data buffer are currently sent in a loop
without any throttling (I plan to add some sort of rate limiting
later). I am not using any of the special DPDK features for IP
fragmention. I am simply preparing and sending mbufs for each
fragment.

The problem I am having is that when I need to send large buffers,
which involve many packets being sent in a tight loop, sometimes part
of the payload is corrupted when received on the other machine. This
is rare and only happens above a certain data rate. I would like to
have a reliable way to detect (or even better, prevent) this
corruption.

Out of paranoia I placed an rte_compiler_barrier() and then an
rte_mb() (a memory barrier) between the code that prepares the mbuf
and the actual tx_burst(). It did not help and I think it should be
unnecessary.

I found some information about the function rte_mbuf_check() and have
started using it to check every received packet on the other end. It
fails to detect this corruption.

Any advice would be appreciated.
-Alan

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-02-05 12:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-02-04 22:36 Corrupted payload when sending many individual mbufs in loop Alan Beadle
2025-02-04 23:26 ` Stephen Hemminger
2025-02-04 23:31   ` Alan Beadle
2025-02-05 12:13     ` Alan Beadle

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