DPDK usage discussions
 help / color / mirror / Atom feed
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).