> -----Original Message----- > From: Andrew Rybchenko [mailto:arybche...@solarflare.com] > Sent: Sunday, September 29, 2019 7:41 PM > To: Su, Simei <simei...@intel.com>; Zhang, Qi Z <qi.z.zh...@intel.com>; Wu, > Jingjing <jingjing...@intel.com>; Ye, Xiaolong <xiaolong...@intel.com>; Yigit, > Ferruh <ferruh.yi...@intel.com> > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 2/3] ethdev: extend RSS offload types > > On 9/29/19 8:11 AM, Simei Su wrote: > > This patch reserves several bits as input set selection from the high > > end of the 64 bits. It is combined with exisiting ETH_RSS_* to > > represent rss types. > > rss -> RSS > > > for example: > > ETH_RSS_IPV4 | ETH_RSS_L3_SRC_ONLY: hash on src ip address only > > ETH_RSS_IPV4_UDP | ETH_RSS_L4_DST_ONLY: hash on src/dst IP and > > dst UDP port > > > > Signed-off-by: Simei Su <simei...@intel.com> > > --- > > lib/librte_ethdev/rte_ethdev.h | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > diff --git a/lib/librte_ethdev/rte_ethdev.h > > b/lib/librte_ethdev/rte_ethdev.h index 7722f70..e68bca8 100644 > > --- a/lib/librte_ethdev/rte_ethdev.h > > +++ b/lib/librte_ethdev/rte_ethdev.h > > @@ -505,6 +505,19 @@ struct rte_eth_rss_conf { > > #define ETH_RSS_GENEVE (1ULL << 20) > > #define ETH_RSS_NVGRE (1ULL << 21) > > > > +/* > > + * We use the following macros to combine with above ETH_RSS_* for > > + * more specific input set selection. These bits are defined starting > > + * from the high end of the 64 bits. > > + * Note: If we use above ETH_RSS_* without SRC/DST_ONLY, it > > +represents > > + * both SRC and DST are taken into account. SRC_ONLY and DST_ONLY of > > + * the same level can't be used simultaneously. > > + */ > > +#define ETH_RSS_L3_SRC_ONLY (1ULL << 63) > > +#define ETH_RSS_L3_DST_ONLY (1ULL << 62) > > +#define ETH_RSS_L4_SRC_ONLY (1ULL << 61) > > +#define ETH_RSS_L4_DST_ONLY (1ULL << 60) > > + > > #define ETH_RSS_IP ( \ > > ETH_RSS_IPV4 | \ > > ETH_RSS_FRAG_IPV4 | \ > > It could be tricky and inconvenient for apps to avoid both ONLY bits on the > same level. E.g. if driver/HW supports both only flags, it will be reported in > caps and if app simply inherits it from caps, both bits will be set.
> > Anyway it requires checks in rte_eth_dev_rss_hash_update() and > rte_eth_dev_configure(). If both only flags are not allows, it should be > checked > and denied. If both only flags are allows and equal to no flags at all, it > should > be simplified automatically to one variant (I would say no flags at all). OK, with more consideration, it seems allow both flags equal to no flags make things more easy.
