From: Slava Ovsiienko <viacheslavo@mellanox.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Thomas Monjalon <thomas@monjalon.net>,
Matan Azrad <matan@mellanox.com>, Ori Kam <orika@mellanox.com>,
Yongseok Koh <yskoh@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata
Date: Tue, 29 Oct 2019 17:43:36 +0000 [thread overview]
Message-ID: <AM4PR05MB32656FEEE8F1E322471A5599D2610@AM4PR05MB3265.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20191029162522.ozj724j7pz7hz753@platinum>
Hi, Olivier
Thanks a lot for the review.
> -----Original Message-----
> From: Olivier Matz <olivier.matz@6wind.com>
> Sent: Tuesday, October 29, 2019 18:25
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>; Matan
> Azrad <matan@mellanox.com>; Ori Kam <orika@mellanox.com>; Yongseok
> Koh <yskoh@mellanox.com>
> Subject: Re: [PATCH v4] ethdev: extend flow metadata
>
> Hi Slava,
>
> Looks good to me overall. Few minor comments below.
>
> On Sun, Oct 27, 2019 at 06:40:36PM +0000, Viacheslav Ovsiienko wrote:
> > Currently, metadata can be set on egress path via mbuf tx_metadata
> > field with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META
> matches metadata.
> >
> > This patch extends the metadata feature usability.
> >
> > 1) RTE_FLOW_ACTION_TYPE_SET_META
> >
> > When supporting multiple tables, Tx metadata can also be set by a rule
> > and matched by another rule. This new action allows metadata to be set
> > as a result of flow match.
> >
> > 2) Metadata on ingress
> >
> > There's also need to support metadata on ingress. Metadata can be set
> > by SET_META action and matched by META item like Tx. The final value
> > set by the action will be delivered to application via metadata
> > dynamic field of mbuf which can be accessed by
> RTE_FLOW_DYNF_METADATA().
> > PKT_RX_DYNF_METADATA flag will be set along with the data.
> >
> > The mbuf dynamic field must be registered by calling
> > rte_flow_dynf_metadata_register() prior to use SET_META action.
> >
> > The availability of dynamic mbuf metadata field can be checked with
> > rte_flow_dynf_metadata_avail() routine.
> >
> > For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> > propagated to the other path depending on hardware capability.
> >
> > Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> > Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
>
> (...)
>
> > diff --git a/lib/librte_ethdev/rte_ethdev.h
> > b/lib/librte_ethdev/rte_ethdev.h index c36c1b6..b19c86b 100644
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -1048,7 +1048,6 @@ struct rte_eth_conf {
> > #define DEV_RX_OFFLOAD_KEEP_CRC 0x00010000
> > #define DEV_RX_OFFLOAD_SCTP_CKSUM 0x00020000
> > #define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM 0x00040000
> > -
> > #define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM
> | \
> > DEV_RX_OFFLOAD_UDP_CKSUM | \
> > DEV_RX_OFFLOAD_TCP_CKSUM)
>
> Undue removed line here.
Right, will fix.
>
> (...)
>
> > +/* Mbuf dynamic field offset for metadata. */ extern int
> > +rte_flow_dynf_metadata_offs;
> > +
> > +/* Mbuf dynamic field flag mask for metadata. */ extern uint64_t
> > +rte_flow_dynf_metadata_mask;
> > +
> > +/* Mbuf dynamic field pointer for metadata. */ #define
> > +RTE_FLOW_DYNF_METADATA(m) \
> > + RTE_MBUF_DYNFIELD((m), rte_flow_dynf_metadata_offs, uint32_t
> *)
> > +
> > +/* Mbuf dynamic flag for metadata. */ #define PKT_RX_DYNF_METADATA
> > +(rte_flow_dynf_metadata_mask)
> > +
> > +__rte_experimental
> > +static inline uint32_t
> > +rte_flow_dynf_metadata_get(struct rte_mbuf *m) {
> > + return *RTE_FLOW_DYNF_METADATA(m);
> > +}
> > +
> > +__rte_experimental
> > +static inline void
> > +rte_flow_dynf_metadata_set(struct rte_mbuf *m, uint32_t v) {
> > + *RTE_FLOW_DYNF_METADATA(m) = v;
> > +}
> > +
>
> (...)
>
> > +__rte_experimental
> > +static inline int
> > +rte_flow_dynf_metadata_avail(void) {
> > + return !!rte_flow_dynf_metadata_mask; }
>
> I think, in DPDK:
>
> static inline void
> rte_flow_dynf_metadata_set(struct rte_mbuf *m, uint32_t v)
> {
> ...
>
> is prefered over:
>
> static inline void
> rte_flow_dynf_metadata_set(struct rte_mbuf *m, uint32_t v) {
Right. It is strange it passed the validator. Will fix.
> ...
>
> > --- a/lib/librte_mbuf/rte_mbuf_dyn.h
> > +++ b/lib/librte_mbuf/rte_mbuf_dyn.h
> > @@ -234,6 +234,10 @@ int rte_mbuf_dynflag_lookup(const char *name,
> > __rte_experimental void rte_mbuf_dyn_dump(FILE *out);
> >
> > -/* Placeholder for dynamic fields and flags declarations. */
> > -
> > +/*
> > + * Placeholder for dynamic fields and flags declarations.
> > + * This is centralizing point to gather all field names
> > + * and parameters together.
> > + */
> > +#define MBUF_DYNF_METADATA_NAME "rte_flow_dynfield_metadata"
> > #endif
>
> The RTE_ prefix is missing. Also, thi name is called dynfield but it is used for
> both field and flag. I suggest RTE_MBUF_DYNFIELD_METADATA_NAME and
> RTE_MBUF_DYNFLAG_METADATA_NAME, to be consistent with the other
> naming conventions in rte_mbuf_dyn.[ch].
Well, it makes sense for complex features, say, with multiple dynaflags.
But it is OK for me, will update.
>
> One more comment: as previously discussed, changing the size or alignement
> of a dynamic field should not be allowed, because it can break the users of
> the field.
>
> Depending on how it is implemented (is the registration function inline?
> is the rte_mbuf_dynfield structure private, shared, or static const in a .h? are
> we using #defines for name, size, align?), I think the impact on users will be
> different. This is something we need to think about for next versions: how to
> detect these changes before pushing the commit, and/or at runtime?
>
I'm not sure if we will have a lot of implementation invariants for dynamic fields.
These ones are intended to be used in datapath, performance is a king. I think if
someone invent the more efficient way to handle dynafields, we'll update the
metadata code either.
> Regards,
> Olivier
next prev parent reply other threads:[~2019-10-29 17:43 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 21:32 [dpdk-dev] [RFC 1/3] " Yongseok Koh
2019-06-03 21:32 ` [dpdk-dev] [RFC 2/3] ethdev: add flow modify mark action Yongseok Koh
2019-06-06 10:35 ` Jerin Jacob Kollanukkaran
2019-06-06 18:33 ` Yongseok Koh
2019-06-03 21:32 ` [dpdk-dev] [RFC 3/3] ethdev: add flow tag Yongseok Koh
2019-07-04 23:23 ` [dpdk-dev] [PATCH] " Yongseok Koh
2019-07-05 13:54 ` Adrien Mazarguil
2019-07-05 18:05 ` Yongseok Koh
2019-07-08 23:32 ` Yongseok Koh
2019-07-09 8:38 ` Adrien Mazarguil
2019-07-11 1:59 ` Yongseok Koh
2019-10-08 12:57 ` Yigit, Ferruh
2019-10-08 13:18 ` Slava Ovsiienko
2019-10-10 16:09 ` [dpdk-dev] [PATCH v2] " Viacheslav Ovsiienko
2019-10-24 13:12 ` [dpdk-dev] [PATCH v3] " Viacheslav Ovsiienko
2019-10-27 16:38 ` Ori Kam
2019-10-27 18:42 ` [dpdk-dev] [PATCH v4] " Viacheslav Ovsiienko
2019-10-27 19:11 ` Ori Kam
2019-10-31 18:57 ` Ferruh Yigit
2019-06-09 14:23 ` [dpdk-dev] [RFC 1/3] ethdev: extend flow metadata Andrew Rybchenko
2019-06-10 3:19 ` Wang, Haiyue
2019-06-10 7:20 ` Andrew Rybchenko
2019-06-11 0:06 ` Yongseok Koh
2019-06-19 9:05 ` Andrew Rybchenko
2019-07-04 23:21 ` [dpdk-dev] [PATCH] " Yongseok Koh
2019-07-10 9:31 ` Olivier Matz
2019-07-10 9:55 ` Bruce Richardson
2019-07-10 10:07 ` Olivier Matz
2019-07-10 12:01 ` Bruce Richardson
2019-07-10 12:26 ` Thomas Monjalon
2019-07-10 16:37 ` Yongseok Koh
2019-07-11 7:44 ` Adrien Mazarguil
2019-07-14 11:46 ` Andrew Rybchenko
2019-07-29 15:06 ` Adrien Mazarguil
2019-10-08 12:51 ` Yigit, Ferruh
2019-10-08 13:17 ` Slava Ovsiienko
2019-10-10 16:02 ` [dpdk-dev] [PATCH v2] " Viacheslav Ovsiienko
2019-10-18 9:22 ` Olivier Matz
2019-10-19 19:47 ` Slava Ovsiienko
2019-10-21 16:37 ` Olivier Matz
2019-10-24 6:49 ` Slava Ovsiienko
2019-10-24 9:22 ` Olivier Matz
2019-10-24 12:30 ` Slava Ovsiienko
2019-10-24 13:08 ` [dpdk-dev] [PATCH v3] " Viacheslav Ovsiienko
2019-10-27 16:56 ` Ori Kam
2019-10-27 18:40 ` [dpdk-dev] [PATCH v4] " Viacheslav Ovsiienko
2019-10-27 19:10 ` Ori Kam
2019-10-29 16:22 ` Andrew Rybchenko
2019-10-29 17:19 ` Slava Ovsiienko
2019-10-29 18:30 ` Thomas Monjalon
2019-10-29 18:35 ` Slava Ovsiienko
2019-10-30 6:28 ` Andrew Rybchenko
2019-10-30 7:35 ` Andrew Rybchenko
2019-10-30 8:59 ` Slava Ovsiienko
2019-10-30 9:20 ` Andrew Rybchenko
2019-10-30 10:05 ` Slava Ovsiienko
2019-10-30 10:03 ` Slava Ovsiienko
2019-10-30 15:49 ` Olivier Matz
2019-10-31 9:25 ` Andrew Rybchenko
2019-10-29 16:25 ` Olivier Matz
2019-10-29 16:33 ` Olivier Matz
2019-10-29 17:53 ` Slava Ovsiienko
2019-10-29 17:43 ` Slava Ovsiienko [this message]
2019-10-29 19:31 ` [dpdk-dev] [PATCH v5] " Viacheslav Ovsiienko
2019-10-30 8:02 ` Andrew Rybchenko
2019-10-30 14:40 ` Slava Ovsiienko
2019-10-30 14:46 ` Slava Ovsiienko
2019-10-30 15:20 ` Olivier Matz
2019-10-30 15:57 ` Thomas Monjalon
2019-10-30 15:58 ` Slava Ovsiienko
2019-10-30 16:13 ` Olivier Matz
2019-10-30 8:35 ` Ori Kam
2019-10-30 17:12 ` [dpdk-dev] [PATCH v6 0/2] extend flow metadata feature Viacheslav Ovsiienko
2019-10-30 17:12 ` [dpdk-dev] [PATCH v6 1/2] ethdev: extend flow metadata Viacheslav Ovsiienko
2019-10-31 9:19 ` Andrew Rybchenko
2019-10-31 13:05 ` [dpdk-dev] [PATCH v7 0/2] extend flow metadata feature Viacheslav Ovsiienko
2019-10-31 13:05 ` [dpdk-dev] [PATCH v7 1/2] ethdev: extend flow metadata Viacheslav Ovsiienko
2019-10-31 15:47 ` Olivier Matz
2019-10-31 16:13 ` Slava Ovsiienko
2019-10-31 16:48 ` [dpdk-dev] [PATCH v8 0/2] extend flow metadata feature Viacheslav Ovsiienko
2019-10-31 16:48 ` [dpdk-dev] [PATCH v8 1/2] ethdev: extend flow metadata Viacheslav Ovsiienko
2019-11-04 6:13 ` [dpdk-dev] [PATCH v9 0/2] extend flow metadata feature Viacheslav Ovsiienko
2019-11-04 6:13 ` [dpdk-dev] [PATCH v9 1/2] ethdev: extend flow metadata Viacheslav Ovsiienko
2019-11-05 14:19 ` [dpdk-dev] [PATCH v10 0/2] extend flow metadata feature Viacheslav Ovsiienko
2019-11-05 14:19 ` [dpdk-dev] [PATCH v10 1/2] ethdev: extend flow metadata Viacheslav Ovsiienko
2019-11-05 14:19 ` [dpdk-dev] [PATCH v10 2/2] ethdev: move egress metadata to dynamic field Viacheslav Ovsiienko
2019-11-06 15:49 ` [dpdk-dev] [PATCH v10 0/2] extend flow metadata feature Ferruh Yigit
2019-11-04 6:13 ` [dpdk-dev] [PATCH v9 2/2] ethdev: move egress metadata to dynamic field Viacheslav Ovsiienko
2019-10-31 16:48 ` [dpdk-dev] [PATCH v8 " Viacheslav Ovsiienko
2019-10-31 17:21 ` Olivier Matz
2019-11-01 12:34 ` Andrew Rybchenko
2019-10-31 13:05 ` [dpdk-dev] [PATCH v7 " Viacheslav Ovsiienko
2019-10-31 13:33 ` Ori Kam
2019-10-31 15:51 ` Olivier Matz
2019-10-31 16:07 ` Slava Ovsiienko
2019-10-30 17:12 ` [dpdk-dev] [PATCH v6 " Viacheslav Ovsiienko
2019-10-31 9:01 ` Andrew Rybchenko
2019-10-31 10:54 ` Slava Ovsiienko
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=AM4PR05MB32656FEEE8F1E322471A5599D2610@AM4PR05MB3265.eurprd05.prod.outlook.com \
--to=viacheslavo@mellanox.com \
--cc=dev@dpdk.org \
--cc=matan@mellanox.com \
--cc=olivier.matz@6wind.com \
--cc=orika@mellanox.com \
--cc=thomas@monjalon.net \
--cc=yskoh@mellanox.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).