From: Thomas Monjalon <thomas@monjalon.net>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: dev@dpdk.org, Rami Rosen <roszenrami@gmail.com>,
olivier.matz@6wind.com, arybchenko@solarflare.com,
ferruh.yigit@intel.com
Subject: Re: [RFC] function to parse packet headers
Date: Thu, 10 Jan 2019 00:57:46 +0100 [thread overview]
Message-ID: <3446539.r5cUhzCBca@xps> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B425B8@smartserver.smartshare.dk>
Adding few more Cc's
09/01/2019 16:53, Morten Brørup:
> From: Rami Rosen [mailto:roszenrami@gmail.com]
> >Hi Morten,
> >A good idea, thanks for volunteering!
> >Several minor comments:
> >I would consider calling it rte_mbuf_hdr_parse(), to make it more related to the rte_mbuf* methods, and also I would consider having it in librte_mbuf and not in librte_net as you suggested.
>
> I considered this, but since it looks inside the packet data, and not just processes metadata, I think it doesn't belong in librte_mbuf.
>
> >
> >Also regarding the bulk method. The first option is indeed faster and better in terms of performance, which is important since it is intended probably mostly to the datapath. I would consider having the bulk method iterating over the rte_hdr_parse() method ,( or rte_mbuf_hdr_parse() if you will agree to my suggestion), and adding a boolean parameter (mark_malform or something like that) to this method + removing the const quailifier. The bulk method will set that flag when calling the rte_hdr_parse(). Thus you will avoid duplicity of the parsing code.
>
> Good points...
>
> And regarding avoiding code duplicity, I'm pursuing Olivier about merging packet header validation into rte_net_get_ptype() instead of writing a separate function.
>
> >
> >Regards,
> >Rami Rosen
next prev parent reply other threads:[~2019-01-09 23:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-08 16:48 [RFC] function to parse packet headers Morten Brørup
2019-01-08 20:09 ` Rami Rosen
2019-01-09 15:53 ` Morten Brørup
2019-01-09 23:57 ` Thomas Monjalon [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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=3446539.r5cUhzCBca@xps \
--to=thomas@monjalon.net \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=mb@smartsharesystems.com \
--cc=olivier.matz@6wind.com \
--cc=roszenrami@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.