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 3ECBFA04C7; Mon, 14 Sep 2020 16:38:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2506D1C0D2; Mon, 14 Sep 2020 16:38:23 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id F04941BE95 for ; Mon, 14 Sep 2020 16:38:20 +0200 (CEST) IronPort-SDR: p0LjXzViGjRXs25rEYJV3+Rrnb7SD4B55aq83/TiFPAarneDWyGBpSjh8/l8rgTNuIS1/6knEx Z+28LQZ5h2FA== X-IronPort-AV: E=McAfee;i="6000,8403,9744"; a="159126426" X-IronPort-AV: E=Sophos;i="5.76,426,1592895600"; d="scan'208";a="159126426" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2020 07:38:17 -0700 IronPort-SDR: WU2C1V6b2gEgxvyujNWMg09kS3UmFMH5yewK9p+aKW2DnyMaDoBEZmCGA3YnF2p+IeBW6lfzLf fng4wdai/qFw== X-IronPort-AV: E=Sophos;i="5.76,426,1592895600"; d="scan'208";a="507164634" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.247.225]) ([10.213.247.225]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2020 07:38:14 -0700 To: Ori Kam , Andrew Rybchenko , Thomas Monjalon , "david.marchand@redhat.com" , John McNamara , Marko Kovacevic Cc: "dev@dpdk.org" References: <1596464905-43867-1-git-send-email-orika@mellanox.com> <1596528811-138806-1-git-send-email-orika@mellanox.com> <5cc28959-f649-f262-eb68-2bf44727c786@solarflare.com> From: Ferruh Yigit Message-ID: Date: Mon, 14 Sep 2020 15:38:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2] doc: update RSS action with best effort 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 8/5/2020 3:08 PM, Ori Kam wrote: > Hi Andrew, > >> -----Original Message----- >> From: Andrew Rybchenko >> >> On 8/4/20 11:13 AM, Ori Kam wrote: >>> Using the rte_flow action RSS types field, >>> may result in undefined outcome. >>> >>> For example selecting both UDP and TCP, >>> selecting TCP RSS type but the pattern is targeting UDP traffic. >>> another option is that the PMD doesn't support all requested types. >>> >>> Until now, it wasn't clear what will happen in such cases. >>> This commit clarify this issue by stating that the PMD >>> will work in the best-effort mode. >>> >>> Signed-off-by: Ori Kam >>> --- >>> v2: >>> * Based on ML, update that using only unsupported hash type >>> may cause the flow to be rejected by PMD. >>> --- >>> doc/guides/prog_guide/rte_flow.rst | 11 +++++++++++ >>> 1 file changed, 11 insertions(+) >>> >>> diff --git a/doc/guides/prog_guide/rte_flow.rst >> b/doc/guides/prog_guide/rte_flow.rst >>> index 3e5cd1e..d730b66 100644 >>> --- a/doc/guides/prog_guide/rte_flow.rst >>> +++ b/doc/guides/prog_guide/rte_flow.rst >>> @@ -1735,6 +1735,17 @@ unspecified "best-effort" settings from the >> underlying PMD, which depending >>> on the flow rule, may result in anything ranging from empty (single queue) >>> to all-inclusive RSS. >>> >>> +Best effort will be used, in case there is a conflict inside the rule. >>> +The conflict can be the result of: >>> + >>> +- Conflicting RSS types, for example setting both UDP and TCP. >> >> Thinking more about it, I see no conflict at all. It is common >> to specify both TCP and UDP in hash function if user wants to >> take TCP ports for TCP packets and UDP ports for UDP into >> account. >> > I fully agree with you that it is common to use both UDP and TCP and > expect it to work based on the traffic. this is the point of this patch. > To clarify that this is valid input and the PMD will work in best effort mode. > I think confusion occurs when the the RSS hash function set part of flow rule rss action. Than providing a UDP flow and setting UDP & TCP RSS hash types looks confusing/wrong. Does mlx support selecting hash function per flow? Can it be possible to set RSS functions separately from any specific flow? > >>> + >>> +- Conflicting between RSS types and the requested pattern to match, >>> + for example matching on UDP and hashing RSS on TCP. >> >> I'd not name it a conflict either. It is just common rule when >> applicable fields are used only. >> > Just like my comment from above. > >>> + >>> +If requested RSS hash type is not supported, >>> +and no supported hash type is requested then the PMD may reject the flow. >>> + >> >> I disagree with such description. If requested RSS hash type is >> not supported (not present in dev_info.flow_type_rss_offloads), >> it must be rejected and error returned. >> If requested RSS hash type is not supported for a packet >> matching the rule, but supported in general (present in >> dev_info.flow_type_rss_offloads), part of RSS hash type >> specification may be ignored and only applicable bits are used. >> If result is empty, PMD may reject the flow rule. >> > The flow should be rejected even if it is used with some type that is supported? > > >>> Note: RSS hash result is stored in the ``hash.rss`` mbuf field which >>> overlaps ``hash.fdir.lo``. Since `Action: MARK`_ sets the ``hash.fdir.hi`` >>> field only, both can be requested simultaneously. >>> >