DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: <dev@dpdk.org>
Subject: [dpdk-dev] [RFC] function to parse packet headers
Date: Tue, 8 Jan 2019 17:48:20 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35B425B1@smartserver.smartshare.dk> (raw)

I'm volunteering to provide a function to set the mbuf's l2_len/l3_len/... (tx_offload) fields by parsing the packet headers, possibly assisted by the packet_type field, if set.

I'm seeking initial feedback before submitting my first version of the code.

The single packet parser function header is straightforward, and returns 0 if OK and -1 if the packet is malformed:
int rte_hdr_parse(struct rte_mbuf * const m);


The bulk parser function needs a well defined and simple way to mark malformed packets, e.g. if the IPv4 header length field value is less than 5. There are multiple ways of doing this.

The bulk function could take the mbuf array as input and simply mark malformed packets by setting MBUF->tx_offload = 0:
void rte_hdr_parse_bulk(struct rte_mbuf **pkts, uint_fast16_t nb_pkts);

Or the bulk function could take both input and output arrays, and return the number of non-malformed packets in the output array like this:
uint_fast16_t rte_hdr_parse_bulk(struct rte_mbuf **pkts_in, struct rte_mbuf **pkts_out, uint_fast16_t nb_pkts_in);

The first is obviously faster. Which do you prefer?


Suggested file location and name:
root/lib/librte_net/rte_hdr_parse.[ch]


PS: Inspired by the discussion about GRO (https://mails.dpdk.org/archives/dev/2019-January/122572.html), where Konstantin called for volunteers. I already have some of it lying around, so I will contribute if useful. But it needs some cleaning up first.


Med venlig hilsen / kind regards

Morten Brørup
CTO


SmartShare Systems A/S
Tonsbakken 16-18
DK-2740 Skovlunde
Denmark

Office      +45 70 20 00 93
Direct      +45 89 93 50 22
Mobile     +45 25 40 82 12

mb@smartsharesystems.com
www.smartsharesystems.com



             reply	other threads:[~2019-01-08 16:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-08 16:48 Morten Brørup [this message]
2019-01-08 20:09 ` Rami Rosen
2019-01-09 15:53   ` Morten Brørup
2019-01-09 23:57     ` Thomas Monjalon
2019-01-10  1:03       ` Rami Rosen
2019-01-11  0:11         ` Stephen Hemminger
2019-01-11  7:56           ` Andrew Rybchenko
2019-01-11  8:16             ` Morten Brørup
2019-01-11  8:28               ` Andrew Rybchenko
2019-01-11  8:35             ` Olivier Matz
2019-01-11  9:49               ` Ananyev, Konstantin
2019-01-11 12:04                 ` Morten Brørup
2019-01-09  3:43 longtb5
2019-01-09 15:38 ` Morten Brørup
2019-01-10  3:25   ` longtb5
2019-01-10  8:21     ` Morten Brørup

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=98CBD80474FA8B44BF855DF32C47DC35B425B1@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=dev@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).