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 B2827A00E6 for ; Fri, 9 Aug 2019 11:23:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DC24C231E; Fri, 9 Aug 2019 11:22:59 +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 1B28A1B19 for ; Fri, 9 Aug 2019 11:22:59 +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-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 0BFD9100063; Fri, 9 Aug 2019 09:22:57 +0000 (UTC) Received: from [192.168.1.11] (85.187.13.152) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 9 Aug 2019 10:22:47 +0100 To: Tom Barbette , , , , , , , , Neil Horman , "John McNamara" , Marko Kovacevic CC: References: <20190808085859.796-1-pbhagavatula@marvell.com> <20190809081740.1607-1-pbhagavatula@marvell.com> <2811f2d9-9c85-0eff-6228-e8c5251587a7@kth.se> From: Andrew Rybchenko Message-ID: Date: Fri, 9 Aug 2019 12:22:30 +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: <2811f2d9-9c85-0eff-6228-e8c5251587a7@kth.se> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [85.187.13.152] 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-24836.000 X-TM-AS-Result: No-8.187900-8.000000-10 X-TMASE-MatchedRID: C/snMIRQLS3mLzc6AOD8DfHkpkyUphL9IiTd2l7lf6FI3vhhM50Zw3HU HCqTYbHt53X12MrxS/cjfw7Mh2lRubXEQlFd70PEA9lly13c/gF9iuvWn3J8KlabQmUcC70Brr5 TE4GLzk1O6Alj8NGlo0gco+3UkqDdl/Hfx9PPkd30VCHd+VQiHrqGBW9J0YqjYy6fApvL8BcGs/ +hIg7uQXSMIFbu4ami00IQ/OgAa/8sO+kVEfVuQnYZxYoZm58FXs5nqGvDCfOHv8otQeUIQh/Qa THp1jSKOcDxuFovi7ssk0l/MfH0rChW3rCVLjscJdOcBmSEp+XLRD51bz5RZBQUOSCpbPwOstfL 6WfCYzHW8NwyKQZv406Zm0CwRJkU5fMkekEWjxtwju9EALAXQgZyESFXAljfKBVvFbsUM5X6J9J Pzr0Fdbn5SCYyL6DP0YcaJEjxXheyG5b8T19QhAdHNpBuxrOoNpy6NoTePCGbKItl61J/ybLn+0 Vm71Lcq7rFUcuGp/EnRE+fI6etkjk8zF34e95f3/8SyxOHeA4gR81p842LUT5Bd0pDdZwcBz1+W svtxcxa0ALjPhXBT3mYaE6GqJ9o40oxmOtlA9rjDOdKPOIS5fAdfn5DyOPDXC6uJnc/p0Ssglkl tB8xdGpozkualSTDOvxFSbveVNw= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--8.187900-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24836.000 X-MDID: 1565342578-q9p9hDZQiPCZ Subject: Re: [dpdk-dev] [patch v4] doc: announce API change in ethdev offload 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 8/9/19 12:13 PM, Tom Barbette wrote: > I think the silent breaking is still not solved for > DEV_RX_OFFLOAD_RSS_HASH and DEV_RX_OFFLOAD_FLOW_MARK. > > An old application will still compile without any problem, but the RSS > hash will not be written and the app will break... They should be > negative. Eg DEV_RX_OFFLOAD_NO_RSS_HASH and DEV_RX_OFFLOAD_NO_FLOW_MARK? > > Then, regarding the idea, are we sure it's better to add a > configuration check/a branch than always copying a few bytes from a > warm cache line to a warm cache line? Or some HW could free some > internal resources? But drivers are free to ignore it so it is not a > problem as opposed to silent breaking. It could be not delivered from NIC to host saving PCIe bandwidth. E.g. flow mark plus RSS hash is 8 byte and it is more than 10% for small packet. > Tom > > On 2019-08-09 10:17, pbhagavatula@marvell.com wrote: >> From: Pavan Nikhilesh >> >> Add new offload flags ``DEV_RX_OFFLOAD_RSS`` and >> ``DEV_RX_OFFLOAD_FLOW_MARK``. >> Add new function ``rte_eth_dev_set_supported_ptypes`` to allow >> application to >> set specific ptypes to be updated in ``rte_mbuf::packet_type`` >> >> Signed-off-by: Pavan Nikhilesh >> Acked-by: Andrew Rybchenko >> Acked-by: Jerin Jacob >> Acked-by: Hemant Agrawal >> --- >>   doc/guides/rel_notes/deprecation.rst | 23 +++++++++++++++++++++++ >>   1 file changed, 23 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst >> b/doc/guides/rel_notes/deprecation.rst >> index 37b8592b6..e4e2a85d7 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -78,3 +78,26 @@ Deprecation Notices >>     to set new power environment if power environment was already >> initialized. >>     In this case the function will return -1 unless the environment >> is unset first >>     (using ``rte_power_unset_env``). Other function usage scenarios >> will not change. >> + >> +* ethdev: New offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and >> ``DEV_RX_OFFLOAD_FLOW_MARK`` >> +  will be added in 19.11. >> +  This will allow application to enable or disable PMDs from updating >> +  ``rte_mbuf::hash::rss`` and ``rte_mbuf::hash::fdir`` respectively. >> +  This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields >> on Rx and >> +  thereby improve Rx performance if application wishes do so. >> +  In 19.11 PMDs will still update the fields even when the offloads >> are not >> +  enabled. >> + >> +* ethdev: New function ``rte_eth_dev_set_supported_ptypes`` will be >> added in >> +  19.11. >> +  This will allow application to request PMD to set specific ptypes >> defined >> +  through ``rte_eth_dev_set_supported_ptypes`` in >> ``rte_mbuf::packet_type``. >> +  If application doesn't want any ptype information it can call >> +  ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_UNKNOWN)`` >> +  If application doesn't call ``rte_eth_dev_set_supported_ptypes`` >> PMD can >> +  return ``rte_mbuf::packet_type`` with >> ``rte_eth_dev_get_supported_ptypes``. >> +  If application is interested only in L2/L3 layer, it can inform >> the PMD to update >> + ``rte_mbuf::packet_type`` with L2/L3 ptype by calling >> + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_L2_MASK | >> RTE_PTYPE_L3_MASK)``. >> +  This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields >> on Rx and >> +  thereby improve Rx performance if application wishes do so. >> -- >> 2.17.1 >>