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 ECB71A04DB; Thu, 15 Oct 2020 16:43:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D5C251E9CE; Thu, 15 Oct 2020 16:43:47 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 7CBB71E9C9 for ; Thu, 15 Oct 2020 16:43:45 +0200 (CEST) IronPort-SDR: zf3YDjh1oXua1TeLOv65M0/JoX6yA5KGQaxSbc35IK5cPzWGhYfKAjiwFGrqRZYpiFpT33d8AU U6uP4kN3gQ8Q== X-IronPort-AV: E=McAfee;i="6000,8403,9774"; a="251056924" X-IronPort-AV: E=Sophos;i="5.77,379,1596524400"; d="scan'208";a="251056924" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2020 07:43:43 -0700 IronPort-SDR: I8X9IU+DL5gLe5wYgCQWP/p+k73M9FNLCC9TcrhnWv3luNiwJTE3+nUgezqrGDJrSROqSLWFZA 4IUQprQa4yEA== X-IronPort-AV: E=Sophos;i="5.77,379,1596524400"; d="scan'208";a="464320522" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.251.84.112]) ([10.251.84.112]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2020 07:43:41 -0700 To: oulijun , wenzhuo.lu@intel.com, beilei.xing@intel.com, adrien.mazarguil@6wind.com Cc: dev@dpdk.org, linuxarm@huawei.com, Ophir Munk , Ori Kam References: <1600955105-53176-2-git-send-email-oulijun@huawei.com> <1602765662-43299-1-git-send-email-oulijun@huawei.com> <1b2b0e11-1458-e2d9-5fde-91db35b8bc73@intel.com> <51676746-ec95-aff2-dc00-b76480ab6cba@huawei.com> From: Ferruh Yigit Message-ID: <8c543941-e881-aa88-b52a-a70bfe8f6fcf@intel.com> Date: Thu, 15 Oct 2020 15:43:37 +0100 MIME-Version: 1.0 In-Reply-To: <51676746-ec95-aff2-dc00-b76480ab6cba@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v5] app/testpmd: fix the default RSS key configuration 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 10/15/2020 3:04 PM, oulijun wrote: > > > 在 2020/10/15 21:52, Ferruh Yigit 写道: >> On 10/15/2020 1:41 PM, Lijun Ou wrote: >>> When start the testpmd, the pmd driver initializes the RSS >>> configuration. Generally, the recommended RSS hash key is >>> used as the default key in the driver. In addition, the >>> default key is different from the default RSS flow in testpmd >>> without specifying RSS hash key. So. if you do not specify >>> the RSS key when creating an RSS rule, the testpmd uses the >>> default key as the default RSS key of the RSS rule. As a result, >>> you may mistakenly consider that the RSS key in use is the valid >>> default key of the NIC, actually, the key and the valid default >>> key of the NIC are two values. >>> >>> Consider the follow usage with testpmd: >>> 1. first, startup testpmd: >>> testpmd> show port 0 rss-hash key >>> RSS functions: >>>    all ipv4-frag ipv4-other ipv6-frag ipv6-other ip >>> RSS key: >>> -6D5A56DA255B0EC24167253D43A38FB0D0CA2BCBAE7B30B477CB2DA38030F >>> -20C6A42B73BBEAC01FA >>> 2. create a rss rule >>> testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end actions rss \ >>> types ipv4-udp end queues end / end >>> >>> 3. show rss-hash key >>> testpmd> show port 0 rss-hash key >>> RSS functions: >>>    all ipv4-udp udp >>> RSS key: >>> -74657374706D6427732064656661756C74205253532068617368206B65792C206F >>> -76657272696465 >>> >>> In order to solve the above problems, it use the NIC valid default >>> RSS key instead of the testpmd dummy RSS key in the flow configuration >>> when the RSS key is not specified in the flow rule. If the NIC RSS key >>> is invalid, it will use testpmd dummy RSS key as the default key. >>> >>> Fixes: ac8d22de2394 ("ethdev: flatten RSS configuration in flow API") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Lijun Ou >>> Reviewed-by: Phil Yang >>> --- >>> V4->V5: >>> -rewrite the commit log >>> -add reviewed-by >> >> Hi Lijun, >> >> There were multiple other comments, it seems they are not addressed but only >> updated the commit log, can you please check comments to prev versions. >> >> Before going into the details, my question was what happens if default key not >> provided at all? >> It seems this has been already tried by Ophir [1], later reverted back [2] >> bringing the initial issue back. >> >> According commit, the reason of revert is to support following command: >> "flow create 0 actions rss queues 0 1 end key_len 40 / end" >> >> @Ophir, @Lijun, >> Can we ignore the 'key_len' if the 'key' is not supported and solve current >> issue as initially intended ([1])? >> > Hi, Ferruh >   I have discussed with Phil Yang about the problem in [1]. I think there may > be other problems with the idea and there is no better solution. and we need to > remove key_len definition from rte_rss_conf structure. They don't have a plan. > And [1] was eventually reverted. > Why ignoring 'key_len' (set it to zero) when there is no 'key' provided doesn't work? > Thanks > Lijun Ou >> >> [1] https://git.dpdk.org/dpdk/commit/?id=a4391f8bae8 >> >> [2] https://git.dpdk.org/dpdk/commit/?id=f3698c3d09a >> . >>