From: Stephen Hemminger <stephen@networkplumber.org>
To: Haiyue Wang <haiyue.wang@intel.com>
Cc: dev@dpdk.org, ferruh.yigit@intel.com,
Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [dpdk-dev] [PATCH v2] net: adjust the header length parse size
Date: Sat, 5 Sep 2020 09:56:27 -0700 [thread overview]
Message-ID: <20200905095618.0844b4b6@hermes.lan> (raw)
In-Reply-To: <20200905030646.374157-1-haiyue.wang@intel.com>
On Sat, 5 Sep 2020 11:06:46 +0800
Haiyue Wang <haiyue.wang@intel.com> wrote:
> Align to the rte_mbuf's design about Tx header length data size for the
> header length parse result.
> struct {
> uint64_t l2_len:7; /* 88: 0 8 */
> uint64_t l3_len:9; /* 88: 7 8 */
> uint64_t l4_len:8; /* 88:16 8 */
> uint64_t tso_segsz:16; /* 88:24 8 */
> uint64_t outer_l3_len:9; /* 88:40 8 */
> uint64_t outer_l2_len:7; /* 88:49 8 */
> };
>
> Now the IPv6 can support bigger extension header.
>
> The below is the structure hole analysis result:
>
> Before:
> struct rte_net_hdr_lens {
> uint8_t l2_len; /* 0 1 */
> uint8_t l3_len; /* 1 1 */
> uint8_t l4_len; /* 2 1 */
> uint8_t tunnel_len; /* 3 1 */
> uint8_t inner_l2_len; /* 4 1 */
> uint8_t inner_l3_len; /* 5 1 */
> uint8_t inner_l4_len; /* 6 1 */
>
> /* size: 7, cachelines: 1, members: 7 */
> /* last cacheline: 7 bytes */
> };
>
> Now:
> struct rte_net_hdr_lens {
> uint64_t l2_len:7; /* 0: 0 8 */
> uint64_t l3_len:9; /* 0: 7 8 */
> uint64_t l4_len:8; /* 0:16 8 */
> uint64_t tunnel_len:8; /* 0:24 8 */
> uint64_t inner_l2_len:7; /* 0:32 8 */
> uint64_t inner_l3_len:9; /* 0:39 8 */
> uint64_t inner_l4_len:8; /* 0:48 8 */
>
> /* size: 8, cachelines: 1, members: 7 */
> /* bit_padding: 8 bits */
> /* last cacheline: 8 bytes */
> };
>
> Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Bitfields are slow to access, compiler has to do mask/shift operations.
And there is no requirement that structure be the same size.
There is no requirement that fields be ordered the same as
the protocol header. Also tunnel length might get big.
Why not:
struct rte_net_hdr_lens {
uint8_t l2_len;
uint8_t inner_l2_len;
uint16_t l3_len;
uint16_t inner_l3_len;
uint16_t tunnel_len;
uint8_t l4_len;
uint8_t inner_l4_len;
};
next prev parent reply other threads:[~2020-09-05 17:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 5:40 [dpdk-dev] [PATCH v1] net: expand the data size of L3 length to 16 bits Haiyue Wang
2020-09-04 18:55 ` Stephen Hemminger
2020-09-05 3:17 ` Wang, Haiyue
2020-09-05 3:06 ` [dpdk-dev] [PATCH v2] net: adjust the header length parse size Haiyue Wang
2020-09-05 16:56 ` Stephen Hemminger [this message]
2020-09-07 2:14 ` Wang, Haiyue
2020-09-07 1:56 ` [dpdk-dev] [PATCH v3] " Haiyue Wang
2020-09-08 14:53 ` Stephen Hemminger
2020-09-18 8:47 ` Ferruh Yigit
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=20200905095618.0844b4b6@hermes.lan \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=haiyue.wang@intel.com \
--cc=olivier.matz@6wind.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 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).