From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Yuan Wang <yuanx.wang@intel.com>,
aman.deep.singh@intel.com, yuying.zhang@intel.com
Cc: xuan.ding@intel.com, yaqi.tang@intel.com, dev@dpdk.org
Subject: Re: [PATCH v3] app/testpmd: fix protocol header display for Rx buffer split
Date: Mon, 7 Nov 2022 14:31:27 +0300 [thread overview]
Message-ID: <3df1c2bc-2b1d-798e-da1f-5907bdf06746@oktetlabs.ru> (raw)
In-Reply-To: <20221107084506.1896422-1-yuanx.wang@intel.com>
On 11/7/22 11:45, Yuan Wang wrote:
> The "show config rxhdrs" cmd displays the configured protocol headers
> that are used for protocol-based buffer split.
> However, it shows inner-ipv6 as inner-ipv4.
>
> This patch fixes that by adjusting the order of condition judgments.
> This patch also uses RTE_PTYPE_*_MASK as masks.
>
> Fixes: 52e2e7edcf48 ("app/testpmd: add protocol-based buffer split")
>
> Signed-off-by: Yuan Wang <yuanx.wang@intel.com>
>
> ---
> v3:
> - use RTE_PTYPE_*_MASK as masks.
> - refactor to use switch statement.
> v2:
> - add fixline.
>
> ---
> app/test-pmd/config.c | 89 +++++++++++++++++++++----------------------
> 1 file changed, 44 insertions(+), 45 deletions(-)
>
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> index e8a1b77c2a..8638dfed11 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -5070,73 +5070,72 @@ show_rx_pkt_segments(void)
>
> static const char *get_ptype_str(uint32_t ptype)
> {
> - if ((ptype & (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP)) ==
> - (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP))
> + switch (ptype & (RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK)) {
> + case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP:
> return "ipv4-tcp";
If I map "ipv4-tcp" to packets types, I get:
RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP
but vice versa it is sufficient to have just
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP
I think such asymmetry in mapping is bad.
> - else if ((ptype & (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP)) ==
> - (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP))
> + case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP:
> return "ipv4-udp";
> - else if ((ptype & (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP)) ==
> - (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP))
> + case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP:
> return "ipv4-sctp";
> - else if ((ptype & (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP)) ==
> - (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP))
> + case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP:
> return "ipv6-tcp";
> - else if ((ptype & (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP)) ==
> - (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP))
> + case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP:
> return "ipv6-udp";
> - else if ((ptype & (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP)) ==
> - (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP))
> + case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP:
> return "ipv6-sctp";
> - else if ((ptype & RTE_PTYPE_L4_TCP) == RTE_PTYPE_L4_TCP)
> + case RTE_PTYPE_L4_TCP:
> return "tcp";
> - else if ((ptype & RTE_PTYPE_L4_UDP) == RTE_PTYPE_L4_UDP)
> + case RTE_PTYPE_L4_UDP:
> return "udp";
> - else if ((ptype & RTE_PTYPE_L4_SCTP) == RTE_PTYPE_L4_SCTP)
> + case RTE_PTYPE_L4_SCTP:
> return "sctp";
> - else if ((ptype & RTE_PTYPE_L3_IPV4_EXT_UNKNOWN) == RTE_PTYPE_L3_IPV4_EXT_UNKNOWN)
> + case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN:
> return "ipv4";
> - else if ((ptype & RTE_PTYPE_L3_IPV6_EXT_UNKNOWN) == RTE_PTYPE_L3_IPV6_EXT_UNKNOWN)
> + case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN:
> return "ipv6";
> - else if ((ptype & RTE_PTYPE_L2_ETHER) == RTE_PTYPE_L2_ETHER)
> + }
> +
> + switch (ptype & RTE_PTYPE_L2_MASK) {
Having many switches here looks confusing. Who defines
priorities? IMHO it should be single switch here and
values should be in exactly the same order as get_ptype().
Ideally both function should be close to each other.
> + case RTE_PTYPE_L2_ETHER:
> return "eth";
> + }
>
> - else if ((ptype & (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP)) ==
> - (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP))
> - return "inner-ipv4-tcp";
> - else if ((ptype & (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP)) ==
> - (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP))
> - return "inner-ipv4-udp";
> - else if ((ptype & (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_SCTP)) ==
> - (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_SCTP))
> - return "inner-ipv4-sctp";
> - else if ((ptype & (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP)) ==
> - (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP))
> + switch (ptype & (RTE_PTYPE_INNER_L3_MASK | RTE_PTYPE_INNER_L4_MASK)) {
> + case RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP:
> return "inner-ipv6-tcp";
get_ptype():
inner-ipv6-tcp -> RTE_PTYPE_TUNNEL_GRENAT | RTE_PTYPE_INNER_L2_ETHER |
RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP
So, mapping is asymmetric again.
Out of topic for the patch:
Also I'm wondering why inner-ipv6-tcp is a grenat. Why not
VxLAN, not GENEVE?
> - else if ((ptype & (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP)) ==
> - (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP))
> + case RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP:
> return "inner-ipv6-udp";
> - else if ((ptype & (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_SCTP)) ==
> - (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_SCTP))
> + case RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_SCTP:
> return "inner-ipv6-sctp";
> - else if ((ptype & RTE_PTYPE_INNER_L4_TCP) == RTE_PTYPE_INNER_L4_TCP)
> + case RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP:
> + return "inner-ipv4-tcp";
> + case RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP:
> + return "inner-ipv4-udp";
> + case RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_SCTP:
> + return "inner-ipv4-sctp";
> + case RTE_PTYPE_INNER_L4_TCP:
> return "inner-tcp";
> - else if ((ptype & RTE_PTYPE_INNER_L4_UDP) == RTE_PTYPE_INNER_L4_UDP)
> + case RTE_PTYPE_INNER_L4_UDP:
> return "inner-udp";
> - else if ((ptype & RTE_PTYPE_INNER_L4_SCTP) == RTE_PTYPE_INNER_L4_SCTP)
> + case RTE_PTYPE_INNER_L4_SCTP:
> return "inner-sctp";
> - else if ((ptype & RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN) ==
> - RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN)
> - return "inner-ipv4";
> - else if ((ptype & RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN) ==
> - RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN)
> + case RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN:
> return "inner-ipv6";
> - else if ((ptype & RTE_PTYPE_INNER_L2_ETHER) == RTE_PTYPE_INNER_L2_ETHER)
> + case RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN:
> + return "inner-ipv4";
> + }
> +
> + switch (ptype & RTE_PTYPE_INNER_L2_MASK) {
> + case RTE_PTYPE_INNER_L2_ETHER:
> return "inner-eth";
> - else if ((ptype & RTE_PTYPE_TUNNEL_GRENAT) == RTE_PTYPE_TUNNEL_GRENAT)
> + }
> +
> + switch (ptype & RTE_PTYPE_TUNNEL_MASK) {
> + case RTE_PTYPE_TUNNEL_GRENAT:
> return "grenat";
> - else
> - return "unsupported";
> + }
> +
> + return "unsupported";
> }
>
> void
next prev parent reply other threads:[~2022-11-07 11:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 17:40 [PATCH] app/testpmd: fix protocol headers " Yuan Wang
2022-10-17 10:03 ` Tang, Yaqi
2022-10-18 14:50 ` [PATCH v2] " Yuan Wang
2022-10-28 2:04 ` Wang, YuanX
2022-11-06 9:58 ` Andrew Rybchenko
2022-11-07 5:55 ` Wang, YuanX
2022-11-07 8:45 ` [PATCH v3] app/testpmd: fix protocol header " Yuan Wang
2022-11-07 8:51 ` Tang, Yaqi
2022-11-07 11:31 ` Andrew Rybchenko [this message]
2022-11-08 13:53 ` Wang, YuanX
2022-11-09 1:37 ` [PATCH v4] " Yuan Wang
2022-11-10 6:55 ` Andrew Rybchenko
2022-11-10 7:49 ` Wang, YuanX
2022-11-10 8:20 ` [PATCH v5] " Yuan Wang
2022-11-10 8:54 ` Andrew Rybchenko
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=3df1c2bc-2b1d-798e-da1f-5907bdf06746@oktetlabs.ru \
--to=andrew.rybchenko@oktetlabs.ru \
--cc=aman.deep.singh@intel.com \
--cc=dev@dpdk.org \
--cc=xuan.ding@intel.com \
--cc=yaqi.tang@intel.com \
--cc=yuanx.wang@intel.com \
--cc=yuying.zhang@intel.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).