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;



socket_id = rte_socket_id();

pktmbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", 131072, 256, 0,
(2048+128), socket_id);



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,


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


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



^ 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

DPDK usage discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/users/0 users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 users users/ https://inbox.dpdk.org/users \
	public-inbox-index users

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git