DPDK usage discussions
 help / color / mirror / Atom feed
* [dpdk-users] DPDK reassembled packet has zero data for length of second fragment's data
@ 2020-12-14 20:16 roy7259
  0 siblings, 0 replies; only message in thread
From: roy7259 @ 2020-12-14 20:16 UTC (permalink / raw)
  To: users

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

 


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

only message in thread, other threads:[~2020-12-14 20:16 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-14 20:16 [dpdk-users] DPDK reassembled packet has zero data for length of second fragment's data roy7259

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