From: <roy7259@gmail.com>
To: <users@dpdk.org>
Subject: [dpdk-users] DPDK reassembled packet has zero data for length of second fragment's data
Date: Mon, 14 Dec 2020 12:16:27 -0800 [thread overview]
Message-ID: <003201d6d256$0178c240$046a46c0$@gmail.com> (raw)
I have observed that fragmenting a IPv4 UDP packet using dpdk
rte_ipv4_fragment_packet() generates 2 packets as expected. When
reassembling using rte_ipv4_frag_reassemble_packet() the end of the
reassembled packet is all zeros. The zeros are the length of the data part
of the second fragment. The same result was obtained using dpdk-20.08.0 and
dpdk-20.11.0 (LTS) versions.
Running CentOS-8.2.2004-x86_64 on Intel C3758 with 16G ram, 4x 1G hugepages
dpdk-20.08.0 had kernel 4.18.0-193.19.1.el8_2.x86_64
dpdk-20.11.0 has kernel 4.18.0-240.1.1.el8_3.x86_64
Subset below of reassembly code involved with some constants replaced and
error checking removed to simplify. Packets are read in burst of 32 max and
code is typical of examples running polled mode. The fragment table is only
updated from the workingThread(), the table is global so
rte_ip_frag_table_statistics_dump(stdout, fragReassambleTblWan) can be
called outside workingThread() for testing. The Wireshark capture was using
dpdk-20.11.0 and is between 2 identical C3758 boxes, one fragmenting and the
other doing reassembly, summarized below.
static struct rte_mempool *pktmbuf_pool = NULL;
struct rte_ip_frag_tbl *fragReassambleTblWan;
Main()
socket_id = rte_socket_id();
pktmbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", 131072, 256, 0,
(2048+128), socket_id);
workingThread()
uint64_t tms;
uint64_t fragCycles;
struct rte_ether_hdr *ethhdr;
struct rte_ipv4_hdr *iphdr4;
struct rte_mbuf *m;
struct rte_mbuf *mx;
struct rte_ip_frag_death_row deathRow;
memset(&deathRow, 0, sizeof(deathRow));
fragCycles = (rte_get_tsc_hz() + MS_PER_S - 1) / MS_PER_S * (8 * MS_PER_S);
lcore_id = rte_lcore_id();
socketFrag = rte_lcore_to_socket_id(lcore_id);
fragReassambleTblWan = rte_ip_frag_table_create(4096, 4, 4096, fragCycles,
socketFrag)
workingThread() processing loop for each packet
tms = rte_rdtsc();
ethhdr = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
iphdr4 = (struct rte_ipv4_hdr *) RTE_PTR_ADD(ethhdr, sizeof(struct
rte_ether_hdr));
if (rte_ipv4_frag_pkt_is_fragmented(iphdr4)) {
m->l2_len = sizeof(*ethhdr);
m->l3_len = sizeof(*iphdr4);
mx = rte_ipv4_frag_reassemble_packet(fragReassambleTblWan, &deathRow, m,
tms, iphdr4);
}
rte_ip_frag_free_death_row(&deathRow, 0);
mx is NULL on first fragment packet as expected. Second fragment and mx is
non-NULL and contains reassembled but end of packet with zeros.
Thank you in advance for your help
Roy
reply other threads:[~2020-12-14 20:16 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='003201d6d256$0178c240$046a46c0$@gmail.com' \
--to=roy7259@gmail.com \
--cc=users@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).