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 E66E5A0613 for ; Tue, 27 Aug 2019 15:44:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B47F71C10C; Tue, 27 Aug 2019 15:44:43 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 119BF1C0D7 for ; Tue, 27 Aug 2019 15:44:42 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id E9FE2A4008C; Tue, 27 Aug 2019 13:44:36 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 27 Aug 2019 14:44:29 +0100 To: Stephen Hemminger , CC: , John McNamara , "Marko Kovacevic" , Thomas Monjalon , Ferruh Yigit , References: <20190821204755.1990-1-pbhagavatula@marvell.com> <20190821204755.1990-3-pbhagavatula@marvell.com> <20190822211853.7bb98687@xps13> From: Andrew Rybchenko Message-ID: Date: Tue, 27 Aug 2019 16:44:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190822211853.7bb98687@xps13> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24872.003 X-TM-AS-Result: No-3.940500-8.000000-10 X-TMASE-MatchedRID: vbSD0OnL8/Ieimh1YYHcKPZvT2zYoYOwC/ExpXrHizyRoQLwUmtovzCW p18HPoW8SjVIFO5E44BCxxedyPqGQS5rFQ7ithY8IAjxomarSPDxuhkRWK22GJ+4ziUPq4LxCYS nwnapRgUS2edRzl3OFIqCmlJNHjcppksMyXDdOsyTeuX4xo2DEK0ld05+83uwzVgwP7ZMYf8Yfj 4uQ0EvjDppiJZ0IVz0WfZfMttD6e+aybjYZdHJR/UwiX15l0tvbaH3VbOE/Tl/Z0SyQdcmEGBCV 2cQfcttdbk6uIpex0jL+XeVWJOy2Tblc6Gei4nlCLQsumV/5S+ZEoWHC6Rh/XT4/S1AY/5LjICY R8WRXj7OH38lNbOoTO0kh8+z6oXjl2U0xIbdl0xmNCKOCsW/OsdtmwbxPlmOikvE2QGlUYTdKUS BW7I322+5ieh24ZYRkZOl7WKIImrvXOvQVlExsCrJhLSjJRVmqE2mwNlIwhfp5JSbK1yYHRx6E9 rqpAr01+xMpseBInfi/QczNvtIFvdU3dwectzcyHq5IFcmWXLdVzf65GDaRzkg9oo6b/Py19nvZ nU36xlTTpCAx/VW0eLOKLdvqEuDwPCtrRVaNPrBKiV1+XI5rrQisFQPfmoc+crICkOzqvho8XTo Pf/MOed9DL3QbsIdVlxr1FJij9s= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--3.940500-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24872.003 X-MDID: 1566913478-TILobgFLvG3o 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] [PATCH v2 2/7] ethdev: add mbuf RSS update as an offload 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/23/19 4:19 AM, Stephen Hemminger wrote: > On Thu, 22 Aug 2019 02:17:50 +0530 > wrote: > >> From: Pavan Nikhilesh >> >> Add new Rx offload flag `DEV_RX_OFFLOAD_RSS_HASH` which can be used to >> enable/disable PMDs write to `rte_mbuf::hash::rss`. >> PMDs notify the validity of `rte_mbuf::hash:rss` to the applcation >> by enabling `PKT_RX_RSS_HASH ` flag in `rte_mbuf::ol_flags`. >> >> Signed-off-by: Pavan Nikhilesh >> Reviewed-by: Andrew Rybchenko > Is this really a good idea? > Every bit of hardware that works on Windows with RSS is required to > supply the hash (for software steering). So if adding an additional > capability, just adds another bit of complexity, code coverage, and one > more thing that won't be tested by everyone. > > If hardware has it why not set it? Adding a branch is more expensive than > an unused assignment. If a PMD sees no gain in disabling the offload and addition branches, nothing obligates PMD to do. Just keep as is - no problem. However, it opens the door to skip delivery of the RSS hash from NIC HW to host CPU if the hash is not required. Why should it be delivered to CPU and eat PCIe bandwidth if the information is not required?