From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 7B39FA00BE;
Wed, 8 Jul 2020 11:45:30 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 2FDA61DA9A;
Wed, 8 Jul 2020 11:45:29 +0200 (CEST)
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
by dpdk.org (Postfix) with ESMTP id A29651D502
for <dev@dpdk.org>; Wed, 8 Jul 2020 11:45:27 +0200 (CEST)
IronPort-SDR: j8LEqQdCBCJv37NPKkvEJag4V37+WQRNQVtkrwjE58xZAYs4ZLY5BXlvgmTOZ3r4iQG/k5AoGn
t/CRpxiqGfyA==
X-IronPort-AV: E=McAfee;i="6000,8403,9675"; a="209298297"
X-IronPort-AV: E=Sophos;i="5.75,327,1589266800"; d="scan'208";a="209298297"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga006.jf.intel.com ([10.7.209.51])
by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
08 Jul 2020 02:45:26 -0700
IronPort-SDR: rVH23jw6WvFbOPkrBRr+NFAHaP07JZHSulLHSq394OnIzjZkXx/umIB2xcP7KvP1IcqzJVvZyI
p4QlOVF9uQ+A==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.75,327,1589266800"; d="scan'208";a="283744306"
Received: from qzhan15-mobl.ccr.corp.intel.com (HELO [10.255.31.190])
([10.255.31.190])
by orsmga006.jf.intel.com with ESMTP; 08 Jul 2020 02:45:23 -0700
To: Thomas Monjalon <thomas@monjalon.net>, xiaolong.ye@intel.com,
beilei.xing@intel.com
Cc: dev@dpdk.org, jia.guo@intel.com, junfeng.guo@intel.com,
simei.su@intel.com, ferruh.yigit@intel.com, arybchenko@solarflare.com,
viacheslavo@mellanox.com, jerinj@marvell.com, ajit.khaparde@broadcom.com
References: <20200612080711.39774-1-junfeng.guo@intel.com>
<20200616081644.23887-1-junfeng.guo@intel.com>
<20200616081644.23887-2-junfeng.guo@intel.com> <3862163.zQz20bWevW@thomas>
From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
Message-ID: <5a8a00e4-0e13-b60f-53e8-644f83ebf0de@intel.com>
Date: Wed, 8 Jul 2020 17:45:22 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <3862163.zQz20bWevW@thomas>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: add new RSS types for IPv6
prefix
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Hi Thomas:
Sorry for late reply, see comment inline.
On 2020/7/7 19:06, Thomas Monjalon wrote:
> 16/06/2020 10:16, Junfeng Guo:
>> This patch defines new RSS offload types for IPv6 prefix with 32, 48,
>> 64 bits of both SRC and DST IPv6 address.
>>
>> Signed-off-by: Junfeng Guo <junfeng.guo@intel.com>
>> ---
>> lib/librte_ethdev/rte_ethdev.h | 51 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 51 insertions(+)
>>
>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>> index 631b146bd..5a7ba36d8 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -538,6 +538,9 @@ struct rte_eth_rss_conf {
>> #define ETH_RSS_L4_DST_ONLY (1ULL << 60)
>> #define ETH_RSS_L2_SRC_ONLY (1ULL << 59)
>> #define ETH_RSS_L2_DST_ONLY (1ULL << 58)
>> +#define ETH_RSS_L3_PRE32 (1ULL << 57)
>> +#define ETH_RSS_L3_PRE48 (1ULL << 56)
>> +#define ETH_RSS_L3_PRE64 (1ULL << 55)
> PRE32, 48 and 64 are not obvious.
> Why is it needed?
there is typical usage for NAT64, which use 32 bit prefix for IPv6
addresses, in this case flows over IPv4 and IPv6 will result in the same
hash value,
as well as 48, 64, which also have some corresponding use cases,
> At least, please add comments for the values of this API.
sure, we will add more comments.
> Do we want to continue with the RTE_ prefix missing?
> Can't we add the prefix for the new values?
32, 48, 64 are typical usage, and consider suffix pair we may add later,
it will cost 6 bits
so far we still have 27 bit left, so it looks like will not be a
problem in following couple releases.
but anyway use 64 bits to represent RSS inputset can't meet the coming
complex RSS usage, we may need to figure out some new APIs and abandon
the old one.
A stacked protocol layer with bit field selector in each layer is under
consideration, hope we can contribute some RFC at some moment. also feel
free let us know
your thought.
>
> Note: ethdev maintainers were not Cc'ed.
> This reason is enough to nack the patch.
sure, will send a new version to follow this
Thanks
Qi
>
>
>