From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 68EDB1041 for ; Wed, 10 Jan 2018 08:55:46 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id AE0224C0059; Wed, 10 Jan 2018 07:55:44 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 10 Jan 2018 07:55:38 +0000 To: Thomas Monjalon , "Yang, Qiming" CC: Shahaf Shuler , References: <20180104181506.153697-1-qiming.yang@intel.com> <1569196.tzFYU9QD0F@xps> <3352601.Q3XN9ClvY9@xps> From: Andrew Rybchenko Message-ID: Date: Wed, 10 Jan 2018 10:55:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <3352601.Q3XN9ClvY9@xps> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23586.003 X-TM-AS-Result: No--14.341900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1515570945-vXP7xvNwn2tm Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [DPDK] lib/librte_ether: add comments RSS flags 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: , X-List-Received-Date: Wed, 10 Jan 2018 07:55:46 -0000 On 01/10/2018 10:38 AM, Thomas Monjalon wrote: > 10/01/2018 03:15, Yang, Qiming: >> From: Thomas Monjalon [mailto:thomas@monjalon.net] >>> 07/01/2018 07:32, Shahaf Shuler: >>>> Saturday, January 6, 2018 12:22 PM, Andrew Rybchenko: >>>> >>>> [..] >>>> >>>>>> #define ETH_RSS_PORT (1ULL << RTE_ETH_FLOW_PORT) >>>>>> +/** Enable RSS offload on VXLAN packets */ >>>>>> #define ETH_RSS_VXLAN (1ULL << RTE_ETH_FLOW_VXLAN) >>>>>> +/** Enable RSS offload on GENEVE packets */ >>>>>> #define ETH_RSS_GENEVE (1ULL << RTE_ETH_FLOW_GENEVE) >>>>>> +/** Enable RSS offload on NVGRE packets */ >>>>>> #define ETH_RSS_NVGRE (1ULL << RTE_ETH_FLOW_NVGRE) >>>>>> >>>>>> #define ETH_RSS_IP ( \ >>>>> These comments just decode the define name and not that useful. What >>>>> would be really useful here is specification of which fields of the >>>>> packet headers are used to calculate hash especially in the case of tunnels. >>>> +1. >>>> >>>> Also maybe some more clarifications, for example: >>>> 1. What is the expected behavior when, for example, setting the >>> ETH_RSS_IPV6_EX and regular IPv6 packet arrives? is RSS apply on it? >>>> 2. What is the expected behavior from the PMD when not supporting one of >>> the RSS types? >>>> For example most of the DPDK examples uses ETH_RSS_IP [1], however >>> very few devices actually supports each and every RSS type. >>>> Assuming such configuration returns with no error, what should application >>> expect when unsupported packet type arrives. >>>> #define ETH_RSS_IP ( \ >>>> ETH_RSS_IPV4 | \ >>>> ETH_RSS_FRAG_IPV4 | \ >>>> ETH_RSS_NONFRAG_IPV4_OTHER | \ >>>> ETH_RSS_IPV6 | \ >>>> ETH_RSS_FRAG_IPV6 | \ >>>> ETH_RSS_NONFRAG_IPV6_OTHER | \ >>>> ETH_RSS_IPV6_EX) >>> +1 >>> We really need a detailed documentation of the. >>> >> I agree with your comments, but the same RSS configuration may have different behavior(RSS offload and input set) in different driver. > This is a bug! > The API must have the same meaning for all drivers. +1 yes, that's what applications expect Of course, different hardware/drivers can and have specifics which should be described in the driver documentation, but default behaviour should be defined. >> Adding driver specific information in rte_ethdev.h is not suitable. >> So I think the best scheme is to update driver's document to detail the exact behavior and add reference doc here. >> >>> It must be at least as detailed as lib/librte_mbuf/rte_mbuf_ptype.h. >>> Thanks