From: Ophir Munk <ophirmu@mellanox.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>,
Andrew Rybchenko <arybchenko@solarflare.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Thomas Monjalon <thomas@monjalon.net>,
Asaf Penso <asafp@mellanox.com>,
Shahaf Shuler <shahafs@mellanox.com>,
Olga Shern <olgas@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and types
Date: Wed, 7 Nov 2018 15:13:07 +0000 [thread overview]
Message-ID: <VI1PR0502MB37432FA937F72761D25EC5C6D1C40@VI1PR0502MB3743.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20181107140604.GL4638@6wind.com>
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, November 07, 2018 4:06 PM
> To: Ophir Munk <ophirmu@mellanox.com>
> Cc: Ferruh Yigit <ferruh.yigit@intel.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; dev@dpdk.org; Thomas Monjalon
> <thomas@monjalon.net>; Asaf Penso <asafp@mellanox.com>; Shahaf
> Shuler <shahafs@mellanox.com>; Olga Shern <olgas@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and
> types
>
> On Wed, Nov 07, 2018 at 12:39:24PM +0000, Ophir Munk wrote:
> > > -----Original Message-----
> > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > Sent: Wednesday, November 07, 2018 11:31 AM
> > > To: Ophir Munk <ophirmu@mellanox.com>
> > > Cc: Ferruh Yigit <ferruh.yigit@intel.com>; Andrew Rybchenko
> > > <arybchenko@solarflare.com>; dev@dpdk.org; Thomas Monjalon
> > > <thomas@monjalon.net>; Asaf Penso <asafp@mellanox.com>; Shahaf
> > > Shuler <shahafs@mellanox.com>; Olga Shern <olgas@mellanox.com>
> > > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key
> > > and types
> > >
> > > On Wed, Nov 07, 2018 at 09:23:42AM +0000, Ophir Munk wrote:
> > > > struct rte_flow_action_rss include fields 'key' and 'types'.
> > > > Field 'key' is a pointer to bytes array (uint8_t *) which contains
> > > > the specific RSS hash key.
> > > > If an application is only interested in default RSS operation it
> > > > should not care about the specific hash key. The application can
> > > > set the hash key to NULL such that any PMD uses its default RSS key.
> > > >
> > > > Field 'types' is a uint64_t bits flag used to specify a specific
> > > > RSS hash type such as ETH_RSS_IP (see ETH_RSS_*).
> > > > If an application does not care about the specific RSS type it can
> > > > set this field to 0 such that any PMD uses its default type.
> > > >
> > > > Signed-off-by: Ophir Munk <ophirmu@mellanox.com>
> > > > ---
> > > > lib/librte_ethdev/rte_flow.h | 9 +++++++--
> > > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/lib/librte_ethdev/rte_flow.h
> > > > b/lib/librte_ethdev/rte_flow.h index c0fe879..ca9e135 100644
> > > > --- a/lib/librte_ethdev/rte_flow.h
> > > > +++ b/lib/librte_ethdev/rte_flow.h
> > > > @@ -1782,10 +1782,15 @@ struct rte_flow_action_rss {
> > > > * through.
> > > > */
> > > > uint32_t level;
> > > > - uint64_t types; /**< Specific RSS hash types (see ETH_RSS_*). */
> > > > + /**
> > > > + * Specific RSS hash types (see ETH_RSS_*),
> > > > + * or 0 for PMD specific default.
> > > > + */
> > > > + uint64_t types;
> > > > uint32_t key_len; /**< Hash key length in bytes. */
> > > > uint32_t queue_num; /**< Number of entries in @p queue. */
> > > > - const uint8_t *key; /**< Hash key. */
> > > > + /** Hash key, or NULL for PMD specific default key. */
> > > > + const uint8_t *key;
> > >
> > > I'd suggest to document that on key_len instead. If key_len is
> > > nonzero, key cannot be NULL anyway.
> >
> > The decision if a key/len combination is valid is done in the PMD action
> validation API.
> > For example, in MLX5 key==NULL and key_len==40 is accepted.
> > The combination key==NULL and key_len==0 should always succeeds,
> however the "must" parameter for RSS default is key==NULL and not
> key_len==0.
>
> I understand this is how the mlx5 PMD implemented it, but my point is that it
> makes more sense API-wise to define key_len == 0 as the trigger for a default
> RSS hash key than key == NULL.
>
> My suggestion is to follow the same trend as memcpy(), mmap(), snprintf()
> and other well-known functions that take a size when dealing with
> NULL/undefined pointers. Only size matters! :)
>
Please let's stay backward compatible and consistent with previous dpdk releases where
key==NULL is used in struct rte_eth_rss_conf (see code snippet in [1]).
We should avoid confusing applications with setting key==NULL with legacy RSS and key_len==0 with rte_flows.
With regard to trends APIs - I was thinking about free() where a NULL pointer is acceptable :)
[1]
File lib/librte_ethdev/rte_ethdev.h:
/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
* If not NULL, the *rss_key* pointer of the *rss_conf* structure points
* to an array holding the RSS key to use for hashing specific header
* fields of received packets. The length of this array should be indicated
* by *rss_key_len* below. Otherwise, a default random hash key is used by
* the device driver.
*
* The *rss_key_len* field of the *rss_conf* structure indicates the length
* in bytes of the array pointed by *rss_key*. To be compatible, this length
* will be checked in i40e only. Others assume 40 bytes to be used as before.
*
* ..........
*/
struct rte_eth_rss_conf {
uint8_t *rss_key; /**< If not NULL, 40-byte hash key. */
uint8_t rss_key_len; /**< hash key length in bytes. */
uint64_t rss_hf; /**< Hash functions to apply - see below. */
};
> --
> Adrien Mazarguil
> 6WIND
next prev parent reply other threads:[~2018-11-07 15:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-03 15:46 [dpdk-dev] [PATCH v1] " Ophir Munk
2018-11-05 13:11 ` Ferruh Yigit
2018-11-05 21:47 ` Thomas Monjalon
2018-11-07 9:23 ` [dpdk-dev] [PATCH v2] " Ophir Munk
2018-11-07 9:31 ` Adrien Mazarguil
2018-11-07 12:39 ` Ophir Munk
2018-11-07 14:06 ` Adrien Mazarguil
2018-11-07 15:13 ` Ophir Munk [this message]
2018-11-07 16:41 ` Adrien Mazarguil
2018-11-08 6:32 ` Andrew Rybchenko
2018-11-08 8:50 ` Ophir Munk
2018-11-08 23:07 ` Yongseok Koh
2018-11-09 8:13 ` Ophir Munk
2018-11-11 9:35 ` Ori Kam
2018-11-13 17:15 ` Adrien Mazarguil
2018-11-13 18:04 ` Ophir Munk
2018-11-13 18:39 ` Shahaf Shuler
2018-11-14 9:40 ` Adrien Mazarguil
2018-11-14 13:51 ` Shahaf Shuler
2018-11-14 15:16 ` Adrien Mazarguil
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=VI1PR0502MB37432FA937F72761D25EC5C6D1C40@VI1PR0502MB3743.eurprd05.prod.outlook.com \
--to=ophirmu@mellanox.com \
--cc=adrien.mazarguil@6wind.com \
--cc=arybchenko@solarflare.com \
--cc=asafp@mellanox.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=olgas@mellanox.com \
--cc=shahafs@mellanox.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).