From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: Ori Kam <orika@nvidia.com>, Ferruh Yigit <ferruh.yigit@amd.com>,
"Dariusz Sosnowski" <dsosnowski@nvidia.com>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Raslan Darawsheh <rasland@nvidia.com>
Subject: RE: [RFC] ethdev: introduce entropy calculation
Date: Thu, 14 Dec 2023 15:25:27 +0000 [thread overview]
Message-ID: <DS0PR11MB7442F093A8E041BDF4C2F2F3EB8CA@DS0PR11MB7442.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MW2PR12MB4666F351CE7E3EF02F53C91BD68CA@MW2PR12MB4666.namprd12.prod.outlook.com>
Hi Ori,
A few questions on top of Ferruh's questions for better understanding the concept inlined below:
> -----Original Message-----
> From: Ori Kam <orika@nvidia.com>
> Sent: Thursday, December 14, 2023 2:17 PM
> To: Ferruh Yigit <ferruh.yigit@amd.com>; Dariusz Sosnowski
> <dsosnowski@nvidia.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> Subject: RE: [RFC] ethdev: introduce entropy calculation
>
> Hi Ferruh,
>
> > -----Original Message-----
> > From: Ferruh Yigit <ferruh.yigit@amd.com>
> > Sent: Thursday, December 14, 2023 1:35 PM
> >
> > On 12/10/2023 8:30 AM, Ori Kam wrote:
> > > When offloading rules with the encap action, the HW may calculate entropy
> > based on the encap protocol.
> > > Each HW can implement a different algorithm.
> > >
> >
> > Hi Ori,
> >
> > Can you please provide more details what this 'entropy' is used for,
> > what is the usecase?
>
> Sure, in some tunnel protocols, for example, VXLAN, NVGE it is possible to add
> entropy value in one of the
> fields of the tunnel. In VXLAN for example it is in the source port,
> From the VXLAN protocol:
> Source Port: It is recommended that the UDP source port number
> be calculated using a hash of fields from the inner packet --
> one example being a hash of the inner Ethernet frame's headers.
> This is to enable a level of entropy for the ECMP/load-
> balancing of the VM-to-VM traffic across the VXLAN overlay.
> When calculating the UDP source port number in this manner, it
> is RECOMMENDED that the value be in the dynamic/private port
> range 49152-65535 [RFC6335].
>
> Since encap groups number of different 5 tuples together, if HW doesn’t know
> how to RSS
> based on the inner application will not be able to get any distribution of packets.
>
> This value is used to reflect the inner packet on the outer header, so distribution
> will be possible.
>
> The main use case is, if application does full offload and implements the encap on
> the RX.
> For example:
> Ingress/FDB match on 5 tuple encap send to hairpin / different port in case of
> switch.
>
Smart idea! So basically the user is able to get an idea on how good the RSS distribution is, correct?
Can you elaborate a bit on how the entropy is measured: is it a number, what is the range of values, does higher value means better, etc.
> The issue starts when there is a miss on the 5 tuple table for example, due to syn
> packet.
> A packet arrives at the application, and then the application offloads the rule.
> So the application must encap the packet and set the same entropy as the HW
> will do for all the rest
> of the packets.
>
How can the app set the entropy?
> >
> >
> > > When the application receives packets that should have been
> > > encaped by the HW, but didn't reach this stage yet (for example TCP SYN
> > packets),
> > > then when encap is done in SW, application must apply
> > > the same entropy calculation algorithm.
> > >> Using the new API application can request the PMD to calculate the
> > > value as if the packet passed in the HW.
> > >
> >
> > So is this new API a datapath API? Is the intention that application
> > call this API per packet that is missing 'entropy' information?
>
> The application will call this API when it gets a packet that it knows, that the rest
> of the
> packets from this connection will be offloaded and encaped by the HW.
> (see above explanation)
>
> >
> > > Signed-off-by: Ori Kam <orika@nvidia.com>
> > > ---
> > > lib/ethdev/rte_flow.h | 49
> > +++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 49 insertions(+)
> > >
> > > diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> > > index affdc8121b..3989b089dd 100644
> > > --- a/lib/ethdev/rte_flow.h
> > > +++ b/lib/ethdev/rte_flow.h
> > > @@ -6753,6 +6753,55 @@ rte_flow_calc_table_hash(uint16_t port_id, const
> > struct rte_flow_template_table
> > > const struct rte_flow_item pattern[], uint8_t
> > pattern_template_index,
> > > uint32_t *hash, struct rte_flow_error *error);
> > >
> > > +/**
> > > + * @warning
> > > + * @b EXPERIMENTAL: this API may change without prior notice.
> > > + *
> > > + * Destination field type for the entropy calculation.
> > > + *
> > > + * @see function rte_flow_calc_encap_entropy
> > > + */
> > > +enum rte_flow_entropy_dest {
> > > + /* Calculate entropy placed in UDP source port field. */
> > > + RTE_FLOW_ENTROPY_DEST_UDP_SRC_PORT,
> > > + /* Calculate entropy placed in NVGRE flow ID field. */
> > > + RTE_FLOW_ENTROPY_DEST_NVGRE_FLOW_ID,
> > > +};
> > > +
> > > +/**
> > > + * @warning
> > > + * @b EXPERIMENTAL: this API may change without prior notice.
> > > + *
> > > + * Calculate the entropy generated by the HW for a given pattern,
> > > + * when encapsulation flow action is executed.
> > > + *
> > > + * @param[in] port_id
> > > + * Port identifier of Ethernet device.
> > > + * @param[in] pattern
> > > + * The values to be used in the entropy calculation.
> > > + * @param[in] dest_field
> > > + * Type of destination field for entropy calculation.
> > > + * @param[out] entropy
> > > + * Used to return the calculated entropy. It will be written in network order,
> > > + * so entropy[0] is the MSB.
> > > + * The number of bytes is based on the destination field type.
> > >
> >
> >
> > Is the size same as field size in the 'dest_field'?
> > Like for 'RTE_FLOW_ENTROPY_DEST_UDP_SRC_PORT' is it two bytes?
>
> Yes,
> >
> >
> > > + * @param[out] error
> > > + * Perform verbose error reporting if not NULL.
> > > + * PMDs initialize this structure in case of error only.
> > > + *
> > > + * @return
> > > + * - (0) if success.
> > > + * - (-ENODEV) if *port_id* invalid.
> > > + * - (-ENOTSUP) if underlying device does not support this functionality.
> > > + * - (-EINVAL) if *pattern* doesn't hold enough information to calculate the
> > entropy
> > > + * or the dest is not supported.
> > > + */
> > > +__rte_experimental
> > > +int
> > > +rte_flow_calc_encap_entropy(uint16_t port_id, const struct rte_flow_item
> > pattern[],
> > > + enum rte_flow_entropy_dest dest_field, uint8_t
> > *entropy,
> > > + struct rte_flow_error *error);
> > > +
> > > #ifdef __cplusplus
> > > }
> > > #endif
Thanks,
Cristian
next prev parent reply other threads:[~2023-12-14 15:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-10 8:30 Ori Kam
2023-12-12 12:19 ` Dariusz Sosnowski
2023-12-14 11:34 ` Ferruh Yigit
2023-12-14 14:16 ` Ori Kam
2023-12-14 15:25 ` Dumitrescu, Cristian [this message]
2023-12-14 17:18 ` Ori Kam
2023-12-14 17:26 ` Stephen Hemminger
2023-12-15 13:44 ` Ferruh Yigit
2023-12-15 16:21 ` Thomas Monjalon
2023-12-16 9:03 ` Andrew Rybchenko
2023-12-27 15:20 ` Ori Kam
2024-01-04 12:57 ` Dumitrescu, Cristian
2024-01-04 14:33 ` Ori Kam
2024-01-04 18:18 ` Thomas Monjalon
2024-01-07 9:37 ` Ori Kam
2023-12-16 9:19 ` Andrew Rybchenko
2023-12-17 10:07 ` Ori Kam
2024-01-12 7:46 ` Andrew Rybchenko
2024-01-21 9: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=DS0PR11MB7442F093A8E041BDF4C2F2F3EB8CA@DS0PR11MB7442.namprd11.prod.outlook.com \
--to=cristian.dumitrescu@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=ferruh.yigit@amd.com \
--cc=orika@nvidia.com \
--cc=rasland@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).