DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>,
	"Su, Simei" <simei.su@intel.com>
Cc: "Wu, Jingjing" <jingjing.wu@intel.com>,
	"Xing, Beilei" <beilei.xing@intel.com>,
	"Yang, Qiming" <qiming.yang@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
Date: Thu, 4 Jul 2019 13:55:14 +0000	[thread overview]
Message-ID: <039ED4275CED7440929022BC67E7061153D5FFD8@SHSMSX105.ccr.corp.intel.com> (raw)
In-Reply-To: <20190704090719.GK4512@6wind.com>



> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Thursday, July 4, 2019 5:07 PM
> To: Su, Simei <simei.su@intel.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Xing, Beilei <beilei.xing@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
> 
> On Thu, Jul 04, 2019 at 12:47:09PM +0800, simei wrote:
> > From: Simei Su <simei.su@intel.com>
> >
> > This RFC introduces inputset structure to rte_flow_action_rss to
> > support input set specific configuration by rte_flow RSS action.
> >
> > We can give an testpmd command line example to make it more clear.
> >
> > For example, below flow selects the l4 port as inputset for any
> > eth/ipv4/tcp packet: #flow create 0 ingress pattern eth / ipv4 / tcp /
> > end actions rss inputset tcp src mask 0xffff dst mask 0xffff /end
> >
> > Signed-off-by: Simei Su <simei.su@intel.com>
> > ---
> >  lib/librte_ethdev/rte_flow.h | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index f3a8fb1..2a455b6 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -1796,6 +1796,9 @@ struct rte_flow_action_rss {
> >  	uint32_t queue_num; /**< Number of entries in @p queue. */
> >  	const uint8_t *key; /**< Hash key. */
> >  	const uint16_t *queue; /**< Queue indices to use. */
> > +	struct rte_flow_item *inputset; /** Provide more specific inputset
> configuration.
> > +					 * ignore spec, only mask.
> > +					 */
> >  };
> >
> >  /**
> 
> To make sure I understand, is this kind of a more flexible version of
> rte_flow_action_rss.types?

Yes
> 
> For instance while specifying .types = ETH_RSS_IPV4 normally covers both
> source and destination addresses, does this approach enable users to perform
> RSS on source IP only? 

Yes, .it is the case to select any subset of 5 tuples or even tunnel header's id for hash

> In which case, what value does the Toeplitz algorithm
> assume for the destination, 0x0? (note: must be documented)

My understanding is src/dst pair is only required for a symmetric case
But for Toeplitz, it is just a hash function, it process a serial of data with specific algorithm, have no idea about which part is src and dst , 
So for ip src only with Toeplitz, dst is not required to be a placeholder..
anything I missed, would you share more insight?

Thanks
Qi

> 
> My opinion is that, unless you know of a hardware which can perform RSS on
> random bytes of a packet, this approach is a bit overkill at this point.
> 
> How about simply adding the needed ETH_RSS_* definitions (e.g.
> ETH_RSS_IPV4_(SRC|DST))? How many are needed?
> 
> There are currently 20 used bits and struct rte_flow_action_rss.types is 64-bit
> wide. I'm sure we can manage something without harming the ABI. Even
> better, you wouldn't need a deprecation notice.
> 
> If you use the suggested approach, please update testpmd and its
> documentation as part of the same patch, thanks.
> 
> --
> Adrien Mazarguil
> 6WIND

  reply	other threads:[~2019-07-04 13:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-04  4:47 simei
2019-07-04  9:07 ` Adrien Mazarguil
2019-07-04 13:55   ` Zhang, Qi Z [this message]
2019-07-04 14:08     ` Adrien Mazarguil
2019-07-09  5:41       ` Zhang, Qi Z
2019-07-09  8:19         ` Jerin Jacob Kollanukkaran

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=039ED4275CED7440929022BC67E7061153D5FFD8@SHSMSX105.ccr.corp.intel.com \
    --to=qi.z.zhang@intel.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=jingjing.wu@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=simei.su@intel.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).