DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Ori Kam <orika@nvidia.com>
Cc: Ivan Malov <ivan.malov@oktetlabs.ru>,
	"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: Sun, 30 May 2021 19:28:05 -0700	[thread overview]
Message-ID: <20210530192805.71f5a8ef@hermes.local> (raw)
In-Reply-To: <BL1PR12MB53352FFAB92FFDFE9E7659F6D6209@BL1PR12MB5335.namprd12.prod.outlook.com>

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.

  reply	other threads:[~2021-05-31  2:28 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 [this message]
2021-06-01 14:17     ` Ivan Malov
2021-06-01 15:10       ` Stephen Hemminger
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=20210530192805.71f5a8ef@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=ivan.malov@oktetlabs.ru \
    --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).