From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 296A5A0487 for ; Thu, 4 Jul 2019 16:09:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E59F41BE41; Thu, 4 Jul 2019 16:09:00 +0200 (CEST) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by dpdk.org (Postfix) with ESMTP id 352431BE38 for ; Thu, 4 Jul 2019 16:08:59 +0200 (CEST) Received: by mail-wr1-f44.google.com with SMTP id z1so2154721wru.13 for ; Thu, 04 Jul 2019 07:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=VNRgW/pK1iKvKdVuZOXmBSfcIc2DfUE8+QDi6pAJ+/g=; b=SpnA2IHerjqrKUv8PmLAf2yhBb3K5OZytx/U+b6VC0N9F3YJa56OeqyH+kpc+f19A4 m9kgPt97a6t6AskNCYIc4/4XgF8GyJMtLZIq36M9S2OvQ7/8MQg7hMHz/IL2VyTVWLf5 YpR7NLkemcZdRIHmXfR6Y4CkjiH9395NXgQJ8QmiBPuqgkR1ksRTzPkJYbzjQFER+fkd upjx6Eec7X0ElSRyuMO89QGctXx2XyP/3p+RtQldQt9vv3MU8TmLIY4n9mR3cVByVKpG +E+akBICDHsCV3p6trC+fI19RwWBFC3HLaS75OAgeRmksqYvW+WDg0QqsXEeHJf6XEXj Th+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=VNRgW/pK1iKvKdVuZOXmBSfcIc2DfUE8+QDi6pAJ+/g=; b=gzIjjqU1m9dr2j+vVhCBM845CwFL8b4FiMu9cxsRHx5uVFMpQP/o+g9JOaDs0nBC/n +Sv/3gIoxbpcRv+UqN53Y5fZbeBf0AGc35wlrz714+pR6mcPlk1y2kwvOwulus1xJr+7 xLS/24JCSmmYD3sVBQ5XJT5rRzOZflP6g/oTBE1bvmntj5Tz0uGUaPZtw+3AZ8De/A6/ 1G7eGtN+EZMBOVCYa6w+/WEpN5LB6ugo2PXEKkgCHP6hkgZCC0VmzwRQUmSSRqfiwGUe PhE3yjtkAIMTkMiwVz3wCKGz+MJwz7e+gne99R1n1qi7hcKznvhUEnxHrnWmYISphAcm Ixfw== X-Gm-Message-State: APjAAAUZw7WHWEnWH9unJ4fvymeYQkCK8uuXLki0yOPqO3gN+OSIAQp5 5BZJ68erONCi2kBP1PwUQm8dUw== X-Google-Smtp-Source: APXvYqy8DGhaG1HocbHZrNO/wstPRYGMR7hFyEegQCSR7KNJCWPK9QVZfzgf9r7vN5rWH3KQX7vpng== X-Received: by 2002:adf:a19e:: with SMTP id u30mr29340500wru.33.1562249338881; Thu, 04 Jul 2019 07:08:58 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id x83sm6199888wmb.42.2019.07.04.07.08.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 07:08:57 -0700 (PDT) Date: Thu, 4 Jul 2019 16:08:56 +0200 From: Adrien Mazarguil To: "Zhang, Qi Z" Cc: "Su, Simei" , "Wu, Jingjing" , "Xing, Beilei" , "Yang, Qiming" , "dev@dpdk.org" Message-ID: <20190704140856.GO4512@6wind.com> References: <1562215629-75520-1-git-send-email-simei.su@intel.com> <20190704090719.GK4512@6wind.com> <039ED4275CED7440929022BC67E7061153D5FFD8@SHSMSX105.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <039ED4275CED7440929022BC67E7061153D5FFD8@SHSMSX105.ccr.corp.intel.com> Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Jul 04, 2019 at 01:55:14PM +0000, Zhang, Qi Z wrote: > > > > -----Original Message----- > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > Sent: Thursday, July 4, 2019 5:07 PM > > To: Su, Simei > > Cc: Zhang, Qi Z ; Wu, Jingjing ; > > Xing, Beilei ; Yang, Qiming ; > > 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 > > > > > > 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 > > > --- > > > 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.. Right, I had symmetric Toeplitz in mind and wondered what would happen when users would not select the required fields. I guess the PMD would have to reject unsupported combinations. > anything I missed, would you share more insight? No, that answers the question, thanks. Now what about my suggestion below? In short: extending ETH_RSS_* assuming there's enough bits left in there, instead of adding a whole new framework and breaking ABI in the process. > > 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