DPDK patches and discussions
 help / color / mirror / Atom feed
From: Gregory Etelson <getelson@nvidia.com>
To: Ori Kam <orika@nvidia.com>,
	NBU-Contact-Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>,
	"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	"jerinjacobk@gmail.com" <jerinjacobk@gmail.com>,
	"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	Slava Ovsiienko <viacheslavo@nvidia.com>,
	Matan Azrad <matan@nvidia.com>,
	Raslan Darawsheh <rasland@nvidia.com>
Subject: Re: [dpdk-dev] [PATCH v5 1/2] ethdev: add packet integrity checks
Date: Sun, 18 Apr 2021 08:15:40 +0000	[thread overview]
Message-ID: <BY5PR12MB483447D4219B4D6E71331957A54A9@BY5PR12MB4834.namprd12.prod.outlook.com> (raw)
In-Reply-To: <DM6PR12MB4987C5522206F13DA1BF0CF7D64C9@DM6PR12MB4987.namprd12.prod.outlook.com>

Hello Thomas,

Please see my comment on the use of RTE_STD_C11 below.

Regards,
Gregory.

> > > Currently, DPDK application can offload the checksum check, and
> > > report it in the mbuf.
> > >
> > > However, as more and more applications are offloading some or all
> > > logic and action to the HW, there is a need to check the packet
> > > integrity so the right decision can be taken.
> > >
> > > The application logic can be positive meaning if the packet is valid
> > > jump / do  actions, or negative if packet is not valid jump to SW /
> > > do actions (like drop)  a, and add default flow
> >
> > There is a typo here. What should it be?
> >
> Simply remove the a.
> 
> > > (match all in low priority) that will direct the miss packet to the
> > > miss path.
> > >
> > > Since currently rte_flow works in positive way the assumption is
> > > that the positive way will be the common way in this case also.
> > >
> > > When thinking what is the best API to implement such feature, we
> > > need to considure the following (in no specific order):
> >
> > s/considure/consider/
> >
> 
> Will fix.
> 
> > > 1. API breakage.
> > > 2. Simplicity.
> > > 3. Performance.
> > > 4. HW capabilities.
> > > 5. rte_flow limitation.
> > > 6. Flexibility.
> > >
> > > First option: Add integrity flags to each of the items.
> > > For example add checksum_ok to ipv4 item.
> > >
> > > Pros:
> > > 1. No new rte_flow item.
> > > 2. Simple in the way that on each item the app can see what checks
> > > are available.
> > >
> > > Cons:
> > > 1. API breakage.
> > > 2. increase number of flows, since app can't add global rule and
> > >    must have dedicated flow for each of the flow combinations, for
> example
> > >    matching on icmp traffic or UDP/TCP  traffic with IPv4 / IPv6 will
> > >    result in 5 flows.
> > >
> > > Second option: dedicated item
> > >
> > > Pros:
> > > 1. No API breakage, and there will be no for some time due to having
> > >    extra space. (by using bits)
> > > 2. Just one flow to support the icmp or UDP/TCP traffic with IPv4 /
> > >    IPv6.
> > > 3. Simplicity application can just look at one place to see all possible
> > >    checks.
> > > 4. Allow future support for more tests.
> > >
> > > Cons:
> > > 1. New item, that holds number of fields from different items.
> > >
> > > For starter the following bits are suggested:
> > > 1. packet_ok - means that all HW checks depending on packet layer
> have
> > >    passed. This may mean that in some HW such flow should be splited
> to
> > >    number of flows or fail.
> > > 2. l2_ok - all check for layer 2 have passed.
> > > 3. l3_ok - all check for layer 3 have passed. If packet doesn't have
> > >    l3 layer this check should fail.
> > > 4. l4_ok - all check for layer 4 have passed. If packet doesn't
> > >    have l4 layer this check should fail.
> > > 5. l2_crc_ok - the layer 2 crc is O.K.
> > > 6. ipv4_csum_ok - IPv4 checksum is O.K. it is possible that the
> > >    IPv4 checksum will be O.K. but the l3_ok will be 0. it is not
> > >    possible that checksum will be 0 and the l3_ok will be 1.
> > > 7. l4_csum_ok - layer 4 checksum is O.K.
> > > 8. l3_len_OK - check that the reported layer 3 len is smaller than the
> > >    frame len.
> > >
> > > Example of usage:
> > > 1. check packets from all possible layers for integrity.
> > >    flow create integrity spec packet_ok = 1 mask packet_ok = 1 .....
> > >
> > > 2. Check only packet with layer 4 (UDP / TCP)
> > >    flow create integrity spec l3_ok = 1, l4_ok = 1 mask l3_ok = 1
> > > l4_ok = 1
> > >
> > > Signed-off-by: Ori Kam <orika@nvidia.com>
> > > ---
> > >  doc/guides/prog_guide/rte_flow.rst     | 20 +++++++++++
> > >  doc/guides/rel_notes/release_21_05.rst |  5 +++
> > >  lib/librte_ethdev/rte_flow.h           | 49
> ++++++++++++++++++++++++++
> > >  3 files changed, 74 insertions(+)
> > >
> > > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > > index e1b93ecedf..1dd2301a07 100644
> > > --- a/doc/guides/prog_guide/rte_flow.rst
> > > +++ b/doc/guides/prog_guide/rte_flow.rst
> > > @@ -1398,6 +1398,26 @@ Matches a eCPRI header.
> > >  - ``hdr``: eCPRI header definition (``rte_ecpri.h``).
> > >  - Default ``mask`` matches nothing, for all eCPRI messages.
> > >
> > > +Item: ``PACKET_INTEGRITY_CHECKS``
> > > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > +
> > > +Matches packet integrity.
> > > +For some devices application needs to enable integration checks in
> > > +HW before using this item.
> > > +
> > > +- ``level``: the encapsulation level that should be checked. level
> > > +0 means the
> > > +  default PMD mode (Can be inner most / outermost). value of 1
> > > +means
> > outermost
> > > +  and higher value means inner header. See also RSS level.
> > > +- ``packet_ok``: All HW packet integrity checks have passed based
> > > +on the
> > max
> > > +  layer of the packet.
> > > +- ``l2_ok``: all layer 2 HW integrity checks passed.
> > > +- ``l3_ok``: all layer 3 HW integrity checks passed.
> > > +- ``l4_ok``: all layer 4 HW integrity checks passed.
> > > +- ``l2_crc_ok``: layer 2 crc check passed.
> > > +- ``ipv4_csum_ok``: ipv4 checksum check passed.
> > > +- ``l4_csum_ok``: layer 4 checksum check passed.
> > > +- ``l3_len_ok``: the layer 3 len is smaller than the frame len.
> > > +
> > >  Actions
> > >  ~~~~~~~
> > >
> > > diff --git a/doc/guides/rel_notes/release_21_05.rst
> > b/doc/guides/rel_notes/release_21_05.rst
> > > index a0b907994a..986f749384 100644
> > > --- a/doc/guides/rel_notes/release_21_05.rst
> > > +++ b/doc/guides/rel_notes/release_21_05.rst
> > > @@ -168,6 +168,11 @@ New Features
> > >      the events across multiple stages.
> > >    * This also reduced the scheduling overhead on a event device.
> > >
> > > +* **Added packet integrity match to RTE flow rules.**
> >
> > Please remove "RTE", it has no meaning. All in DPDK is "RTE".
> >
> 
> Sure.
> 
> > > +
> > > +  * Added ``PACKET_INTEGRITY_CHECKS`` flow item.
> >
> > It is RTE_FLOW_ITEM_TYPE_INTEGRITY
> >
> > > +  * Added ``rte_flow_item_integrity`` data structure.
> > > +
> >
> > This text should be sorted before drivers.
> >
> 
> Sure.
> 
> > > --- a/lib/librte_ethdev/rte_flow.h
> > > +++ b/lib/librte_ethdev/rte_flow.h
> > > @@ -551,6 +551,17 @@ enum rte_flow_item_type {
> > >  	 * See struct rte_flow_item_geneve_opt
> > >  	 */
> > >  	RTE_FLOW_ITEM_TYPE_GENEVE_OPT,
> > > +
> > > +	/**
> > > +	 * [META]
> > > +	 *
> > > +	 * Matches on packet integrity.
> > > +	 * For some devices application needs to enable integration checks
> > > +in
> > HW
> > > +	 * before using this item.
> >
> > That's a bit fuzzy.
> > Do you mean some driver-specific API may be required?
> >
> 
> I know it is a bit fuzzy but it is really HW dependent, for example in case of
> some drivers there is nothing to be done.
> In other cases the application may need to enable the RX checksum offload,
> other drivers may need this cap be enabled by HW configuration.
> 
> > > +	 *
> > > +	 * See struct rte_flow_item_integrity.
> > > +	 */
> > > +	RTE_FLOW_ITEM_TYPE_INTEGRITY,
> > >  };
> >
> > > +__extension__
> >
> > Why extension here?
> > If this is because of the anonymous union, it should be RTE_STD_C11
> > before the union.
> > Same for the struct.
> >
> O.K
> 

The RTE_STD_C11 macro fails compilation on 
RHEL-7.9 with gcc version 4.8.5 20150623 (Red Hat 4.8.5-44)

> > > +struct rte_flow_item_integrity {
> > > +	uint32_t level;
> > > +	/**< Packet encapsulation level the item should apply to.
> > > +	 * @see rte_flow_action_rss
> > > +	 */
> >
> > Please insert comments before the struct member.
> >
> O.K.
> 
> > Instead of "Packet encapsulation", isn't it better understood as
> > "Tunnel encapsulation"? Not sure, please advise.
> >
> I have no strong feeling ether way, so I don't mind the change if you think it
> is clearer.
> 
> > > +	union {
> > > +		struct {
> > > +			uint64_t packet_ok:1;
> > > +			/** The packet is valid after passing all HW checks.
> */
> >
> > The doxygen syntax is missing < but it will be fine when moved before.
> >
> Sure.
> 
> > > +			uint64_t l2_ok:1;
> > > +			/**< L2 layer is valid after passing all HW checks. */
> > > +			uint64_t l3_ok:1;
> > > +			/**< L3 layer is valid after passing all HW checks. */
> > > +			uint64_t l4_ok:1;
> > > +			/**< L4 layer is valid after passing all HW checks. */
> > > +			uint64_t l2_crc_ok:1;
> > > +			/**< L2 layer crc is valid. */
> >
> > s/crc/CRC/
> >
> O.K.
> 
> > > +			uint64_t ipv4_csum_ok:1;
> > > +			/**< IPv4 layer checksum is valid. */
> > > +			uint64_t l4_csum_ok:1;
> > > +			/**< L4 layer checksum is valid. */
> > > +			uint64_t l3_len_ok:1;
> > > +			/**< The l3 len is smaller than the frame len. */
> >
> > s/len/length/g
> >
> O.K.
> 
> > > +			uint64_t reserved:56;
> > > +		};
> > > +		uint64_t  value;
> >
> > double space
> >
> Sure.
> 
> > > +	};
> > > +};
> > > +
> > > +#ifndef __cplusplus
> > > +static const struct rte_flow_item_integrity
> > > +rte_flow_item_integrity_mask = {
> > > +	.level = 0,
> > > +	.value = 0,
> > > +};
> > > +#endif
> >
> > I'm pretty sure it breaks with some C compilers.
> > Why not for C++?
> > I see we have it already in rte_flow.h so we can keep it, but that's
> > something to double check for a future fix.
> >
> Just like you said this is the practice used already,
> 
> >


  reply	other threads:[~2021-04-18  8:15 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05 18:04 [dpdk-dev] [PATCH] " Ori Kam
2021-04-06  7:39 ` Jerin Jacob
2021-04-07 10:32   ` Ori Kam
2021-04-07 11:01     ` Jerin Jacob
2021-04-07 22:15       ` Ori Kam
2021-04-08  7:44         ` Jerin Jacob
2021-04-11  4:12           ` Ajit Khaparde
2021-04-11  6:03             ` Ori Kam
2021-04-13 15:16     ` [dpdk-dev] [PATCH v3 0/2] " Gregory Etelson
2021-04-13 15:16       ` [dpdk-dev] [PATCH v3 1/2] ethdev: " Gregory Etelson
2021-04-13 15:16       ` [dpdk-dev] [PATCH v3 2/2] app/testpmd: add support for integrity item Gregory Etelson
2021-04-13 17:15         ` Ferruh Yigit
2021-04-14 12:56     ` [dpdk-dev] [PATCH v4 0/2] add packet integrity checks Gregory Etelson
2021-04-14 12:56       ` [dpdk-dev] [PATCH v4 1/2] ethdev: " Gregory Etelson
2021-04-14 13:27         ` Ferruh Yigit
2021-04-14 13:31           ` Ferruh Yigit
2021-04-14 12:57       ` [dpdk-dev] [PATCH v4 2/2] app/testpmd: add support for integrity item Gregory Etelson
2021-04-14 16:09     ` [dpdk-dev] [PATCH v5 0/2] add packet integrity checks Gregory Etelson
2021-04-14 16:09       ` [dpdk-dev] [PATCH v5 1/2] ethdev: " Gregory Etelson
2021-04-14 17:24         ` Ajit Khaparde
2021-04-15 15:10           ` Ori Kam
2021-04-15 15:25             ` Ajit Khaparde
2021-04-15 16:46         ` Thomas Monjalon
2021-04-16  7:43           ` Ori Kam
2021-04-18  8:15             ` Gregory Etelson [this message]
2021-04-18 18:00               ` Thomas Monjalon
2021-04-14 16:09       ` [dpdk-dev] [PATCH v5 2/2] app/testpmd: add support for integrity item Gregory Etelson
2021-04-14 16:26       ` [dpdk-dev] [PATCH v5 0/2] add packet integrity checks Ferruh Yigit
2021-04-18 15:51     ` [dpdk-dev] [PATCH v6 " Gregory Etelson
2021-04-18 15:51       ` [dpdk-dev] [PATCH v6 1/2] ethdev: " Gregory Etelson
2021-04-18 18:11         ` Thomas Monjalon
2021-04-18 19:24           ` Gregory Etelson
2021-04-18 21:30             ` Thomas Monjalon
2021-04-18 15:51       ` [dpdk-dev] [PATCH v6 2/2] app/testpmd: add support for integrity item Gregory Etelson
2021-04-19  8:29     ` [dpdk-dev] [PATCH v7 0/2] add packet integrity checks Gregory Etelson
2021-04-19  8:29       ` [dpdk-dev] [PATCH v7 1/2] ethdev: " Gregory Etelson
2021-04-19  8:47         ` Thomas Monjalon
2021-04-19  8:29       ` [dpdk-dev] [PATCH v7 2/2] app/testpmd: add support for integrity item Gregory Etelson
2021-04-19 11:20       ` [dpdk-dev] [PATCH v7 0/2] add packet integrity checks Ferruh Yigit
2021-04-19 12:08         ` Gregory Etelson
2021-04-19 12:44     ` [dpdk-dev] [PATCH v8 " Gregory Etelson
2021-04-19 12:44       ` [dpdk-dev] [PATCH v8 1/2] ethdev: " Gregory Etelson
2021-04-19 14:09         ` Ajit Khaparde
2021-04-19 16:34           ` Thomas Monjalon
2021-04-19 17:06             ` Ferruh Yigit
2021-04-19 12:44       ` [dpdk-dev] [PATCH v8 2/2] app/testpmd: add support for integrity item Gregory Etelson
2021-04-19 14:09         ` Ajit Khaparde
2021-04-08  8:04 ` [dpdk-dev] [PATCH] ethdev: add packet integrity checks Andrew Rybchenko
2021-04-08 11:39   ` Ori Kam
2021-04-09  8:08     ` Andrew Rybchenko
2021-04-11  6:42       ` Ori Kam
2021-04-11 17:30         ` Ori Kam
2021-04-11 17:34 ` [dpdk-dev] [PATCH v2 0/2] " Gregory Etelson
2021-04-11 17:34   ` [dpdk-dev] [PATCH v2 1/2] ethdev: " Gregory Etelson
2021-04-12 17:36     ` Ferruh Yigit
2021-04-12 19:26       ` Ori Kam
2021-04-12 23:31         ` Ferruh Yigit
2021-04-13  7:12           ` Ori Kam
2021-04-13  8:03             ` Ferruh Yigit
2021-04-13  8:18               ` Ori Kam
2021-04-13  8:30                 ` Ferruh Yigit
2021-04-13 10:21                   ` Ori Kam
2021-04-13 17:28                     ` Ferruh Yigit
2021-04-11 17:34   ` [dpdk-dev] [PATCH v2 2/2] app/testpmd: add support for integrity item Gregory Etelson
2021-04-12 17:49     ` Ferruh Yigit
2021-04-13  7:53       ` Ori Kam
2021-04-13  8:14         ` Ferruh Yigit
2021-04-13 11:36           ` Ori Kam

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=BY5PR12MB483447D4219B4D6E71331957A54A9@BY5PR12MB4834.namprd12.prod.outlook.com \
    --to=getelson@nvidia.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=matan@nvidia.com \
    --cc=olivier.matz@6wind.com \
    --cc=orika@nvidia.com \
    --cc=rasland@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.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).