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.
next prev parent 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).