DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Ivan Malov <Ivan.Malov@oktetlabs.ru>
Cc: Ori Kam <orika@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>,
	NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Ray Kinsella <mdr@ashroe.eu>, Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: add support for testpmd-compliant flow rule dumping
Date: Tue, 1 Jun 2021 08:10:19 -0700	[thread overview]
Message-ID: <20210601081019.0099bf27@hermes.local> (raw)
In-Reply-To: <949c8087-501f-5618-6fda-2b856ba0ec33@oktetlabs.ru>

On Tue, 1 Jun 2021 17:17:24 +0300
Ivan Malov <Ivan.Malov@oktetlabs.ru> wrote:

> Hi Stephen,
> 
> I agree that the API rte_flow_snprint() itself would look better if it 
> provided the number of characters in its return value, like snprintf 
> does. However, with respect to all internal helpers, this wouldn't be 
> that clear and simple: one would have to update the buffer pointer and 
> decrease the buffer size before each internal (smaller) helper 
> invocation. That would make the code more cumbersome in many places.
> 
> In v2, I will at least try to make the main API return the number of 
> characters. Other than that, it can be discussed further.
> 
> Thank you.
> 
> On 31/05/2021 05:28, Stephen Hemminger wrote:
> > On Sun, 30 May 2021 07:27:32 +0000
> > Ori Kam <orika@nvidia.com> wrote:
> >   
> >>>
> >>> DPDK applications (for example, OvS) or tests which use RTE flow API need to
> >>> log created or rejected flow rules to help to recognise what goes right or
> >>> wrong. From this standpoint, testpmd-compliant format is nice for the
> >>> purpose because it allows to copy-paste the flow rules and debug using
> >>> testpmd.
> >>>
> >>> Recognisable pattern items:
> >>> VOID, VF, PF, PHY_PORT, PORT_ID, ETH, VLAN, IPV4, IPV6, UDP, TCP, VXLAN,
> >>> NVGRE, GENEVE, MARK, PPPOES, PPPOED.
> >>>
> >>> Recognisable actions:
> >>> VOID, JUMP, MARK, FLAG, QUEUE, DROP, COUNT, RSS, PF, VF, PHY_PORT,
> >>> PORT_ID, OF_POP_VLAN, OF_PUSH_VLAN, OF_SET_VLAN_VID,
> >>> OF_SET_VLAN_PCP, VXLAN_ENCAP, VXLAN_DECAP.
> >>>
> >>> Recognisable RSS types (action RSS):
> >>> IPV4, FRAG_IPV4, NONFRAG_IPV4_TCP, NONFRAG_IPV4_UDP,
> >>> NONFRAG_IPV4_OTHER, IPV6, FRAG_IPV6, NONFRAG_IPV6_TCP,
> >>> NONFRAG_IPV6_UDP, NONFRAG_IPV6_OTHER, IPV6_EX, IPV6_TCP_EX,
> >>> IPV6_UDP_EX, L3_SRC_ONLY, L3_DST_ONLY, L4_SRC_ONLY, L4_DST_ONLY.
> >>>
> >>> Unrecognised parts of the flow specification are represented by tokens
> >>> "{unknown}" and "{unknown bits}". Interested parties are welcome to
> >>> extend this tool to recognise more items and actions.
> >>>
> >>> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
> >>> ---
> >>>   lib/ethdev/meson.build        |    1 +
> >>>   lib/ethdev/rte_flow.h         |   33 +
> >>>   lib/ethdev/rte_flow_snprint.c | 1681
> >>> +++++++++++++++++++++++++++++++++
> >>>   lib/ethdev/version.map        |    3 +
> >>>   4 files changed, 1718 insertions(+)
> >>>   create mode 100644 lib/ethdev/rte_flow_snprint.c
> >>>
> >>> diff --git a/lib/ethdev/meson.build b/lib/ethdev/meson.build index
> >>> 0205c853df..97bba4fa1b 100644
> >>> --- a/lib/ethdev/meson.build
> >>> +++ b/lib/ethdev/meson.build
> >>> @@ -8,6 +8,7 @@ sources = files(
> >>>           'rte_class_eth.c',
> >>>           'rte_ethdev.c',
> >>>           'rte_flow.c',
> >>> +	'rte_flow_snprint.c',
> >>>           'rte_mtr.c',
> >>>           'rte_tm.c',
> >>>   )
> >>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
> >>> 961a5884fe..cd5e9ef631 100644
> >>> --- a/lib/ethdev/rte_flow.h
> >>> +++ b/lib/ethdev/rte_flow.h
> >>> @@ -4288,6 +4288,39 @@ rte_flow_tunnel_item_release(uint16_t port_id,
> >>>   			     struct rte_flow_item *items,
> >>>   			     uint32_t num_of_items,
> >>>   			     struct rte_flow_error *error);
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this API may change without prior notice
> >>> + *
> >>> + * Dump testpmd-compliant textual representation of the flow rule.
> >>> + * Invoke this with zero-size buffer to learn the string size and
> >>> + * invoke this for the second time to actually dump the flow rule.
> >>> + * The buffer size on the second invocation = the string size + 1.
> >>> + *
> >>> + * @param[out] buf
> >>> + *   Buffer to save the dump in, or NULL
> >>> + * @param buf_size
> >>> + *   Buffer size, or 0
> >>> + * @param[out] nb_chars_total
> >>> + *   Resulting string size (excluding the terminating null byte)
> >>> + * @param[in] attr
> >>> + *   Flow rule attributes.
> >>> + * @param[in] pattern
> >>> + *   Pattern specification (list terminated by the END pattern item).
> >>> + * @param[in] actions
> >>> + *   Associated actions (list terminated by the END action).
> >>> + *
> >>> + * @return
> >>> + *   0 on success, a negative errno value otherwise
> >>> + */
> >>> +__rte_experimental
> >>> +int
> >>> +rte_flow_snprint(char *buf, size_t buf_size, size_t *nb_chars_total,
> >>> +		 const struct rte_flow_attr *attr,
> >>> +		 const struct rte_flow_item pattern[],
> >>> +		 const struct rte_flow_action actions[]);
> >>> +  
> > 
> > The code would be clearer and simpler if you adopted the same return value
> > as snprintf. Then lots of places could be just tail calls and the nb_chars_total
> > would be unnecessary.
> >   
> 

One other thing. Code for this kind of thing grows like a weed.
It would be good to change from if/else/switch to a more table driven
approach.

  reply	other threads:[~2021-06-01 15:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27  8:25 Ivan Malov
2021-05-30  7:27 ` Ori Kam
2021-05-31  2:28   ` Stephen Hemminger
2021-06-01 14:17     ` Ivan Malov
2021-06-01 15:10       ` Stephen Hemminger [this message]
2021-06-01 14:08   ` Ivan Malov
2021-06-02 13:32     ` Ori Kam
2021-06-02 13:49       ` Andrew Rybchenko
2021-06-03  8:25         ` Ori Kam
2021-06-03  8:43           ` Andrew Rybchenko
2021-06-03  9:27             ` Ori Kam
2023-03-23 12:54               ` Ferruh Yigit
2021-06-02 20:48   ` Stephen Hemminger
2021-06-14 12:42 ` Singh, Aman Deep
2021-06-17  8:11   ` Singh, Aman Deep
2021-07-02 10:20   ` 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=20210601081019.0099bf27@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=Ivan.Malov@oktetlabs.ru \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=mdr@ashroe.eu \
    --cc=nhorman@tuxdriver.com \
    --cc=orika@nvidia.com \
    --cc=thomas@monjalon.net \
    /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).