From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 5C64E1B01F for ; Wed, 10 Jan 2018 08:39:25 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B342B20C6A; Wed, 10 Jan 2018 02:39:24 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 10 Jan 2018 02:39:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=7+Cr2/jtVHKOYvrO9vxVczuzV0 3cgrmO+rE29hIe7PE=; b=UCMWR2c5AQZbNnN/PXZQkkQFLvJfgt7kWiwlbL3lB5 s2AWT3aRgfCkQtDZCeH4N7y/0dxJ3j4cS3zfw6YgL7LAr6+zzVyS1bLnZzILelGF FjWblEiYB0qpjqiZzp9S7r862N6psKQdeLMOGWxpm4udGvyoHLiR4fjGd01ppxqn 0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=7+Cr2/ jtVHKOYvrO9vxVczuzV03cgrmO+rE29hIe7PE=; b=VxErro9JMt28m/Zx9dbtoi 4ew8agtdhfzOKLm3XXct/6V6YolSj/SQ4beHI3QsMonRDbpBTXqAy+Wn7xSAZigT kxv4H+ya9WF6GigfR7LOP0bK+tDZNEo0jc7GX6EF7Jmn+pVO1SMl35X4Jc3j0D5K ZyZ5g2ZEBqq7WDLLagfrVvTG4Gk6aJPvtt7dj6J1Hp71sYypSWmTwq+u+qz5RSI/ ihgoUwUq8BYzSnQRLBvwuoQwDcZQC4CefZaza7h3mFmvakpPuRS+kcS6FNt7DWuW 3iBN4Z9pxFN/29Rr9CPt+AsPHmMhdO5R7X4inc6lGeBpnOw0AdfuBiJfVebCUTGg == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 5E7127E351; Wed, 10 Jan 2018 02:39:24 -0500 (EST) From: Thomas Monjalon To: "Yang, Qiming" Cc: Shahaf Shuler , Andrew Rybchenko , dev@dpdk.org Date: Wed, 10 Jan 2018 08:38:56 +0100 Message-ID: <3352601.Q3XN9ClvY9@xps> In-Reply-To: References: <20180104181506.153697-1-qiming.yang@intel.com> <1569196.tzFYU9QD0F@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:39:25 -0000 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. > 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