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 78305A00E6 for ; Wed, 7 Aug 2019 17:44:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 78FFF2BCE; Wed, 7 Aug 2019 17:44:42 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id BBD032BC7 for ; Wed, 7 Aug 2019 17:44:41 +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-us5.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 4D2A74C005C; Wed, 7 Aug 2019 15:44:40 +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; Wed, 7 Aug 2019 16:44:34 +0100 To: Stephen Hemminger CC: Jerin Jacob Kollanukkaran , "Pavan Nikhilesh Bhagavatula" , Hemant Agrawal , "dev@dpdk.org" References: <5ebb1ff8-3f44-c1ab-ead7-64727e0dd0a6@solarflare.com> <20190807082215.0ef3f6ae@hermes.lan> From: Andrew Rybchenko Message-ID: Date: Wed, 7 Aug 2019 18:44:31 +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: <20190807082215.0ef3f6ae@hermes.lan> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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-24828.000 X-TM-AS-Result: No-7.816800-8.000000-10 X-TMASE-MatchedRID: B0+RG8xpjtT4ECMHJTM/ufZvT2zYoYOwt3aeg7g/usAutoY2UtFqGBlg ra56oHr6qmgjSDIYwlA8GNWjfeMm9aqkg+o+yGWucI7vRACwF0IHgh3sKJBzP6ZqsdAj8YIt4vF 69pWV59G39IjDtOCtdWJES4eKERjmmz6Ddn99ld1hXXywTJLpfDuDayXS0LqB5wA4LRxAiq9ueM FwDJsv/I21Kobj+A4Brs4c77Ktk7VUIV59BFXczhFnPs2NvAjSWNbBpQ++I1mZt08TfNy6OIgnL dHU7oiOCKRTUHgPhBxTeY5oKlk6L87krHcMds8IZdorcofH/GkPo0vi0aZfNYJMlS+kMGbcbIBu 7UhxFGt9b4P7DjqPCjTOQMVmUXsErjaWIU+gleSioOQqyjC146CHGfJA0hsdSStniYWNNsMSzQy AOiK7shW1IHF3Q90x7Iags3qD74m5VsDhdx2cmPVY7U3NX8JgSARj+CV/z5LI9EDAP/dptjFjPe JY99m0Qlj/MQAXNzt7RsoaLgiWOhLUsPoJcoufKrDHzH6zmUUP6OWzRxLAk8G/LoRzLe7s8fX8/ dcuseVeRQwZXtfAVUMdmVcUUe866Ne/nacGH0GcxB01DrjF9zRpdOU52PyTEF+dY4sEoKmvjt6f cRc4A6PElFqGhlJnXe6ZENPqWPph44VlLBLudB23b+lJHvPAnKpQna4coUBDxRz4rfQjRooqqJH JHX2WgiUqouc8uoAWaIGlrsAXgqP0c+Fe+7bk+tBIK6hI4N9jGOJ4njvVGpsoi2XrUn/JyeMtMD 9QOgChMIDkR/KfwI2j49Ftap9E4kYXbobxJbKYLcIscfQKLDhXFuHDEI6gHEREhZrqyuvj73tzr bzrCWXaNsOqECTJ0m7I1OnhspeHq4Qwacn0CTg8Hbbq8LltvdW5O4uzS2Lk7zSbkZ3uPofMZMeg LDIeGU0pKnas+RbnCJftFZkZizYJYNFU00e7N+XOQZygrvY= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--7.816800-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24828.000 X-MDID: 1565192681-2_XCDMa7nQBH Subject: Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx 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/7/19 6:22 PM, Stephen Hemminger wrote: > On Wed, 7 Aug 2019 11:32:35 +0300 > Andrew Rybchenko wrote: > >> On 8/7/19 5:04 AM, Jerin Jacob Kollanukkaran wrote: >>>> -----Original Message----- >>>> From: Stephen Hemminger >>>> Sent: Wednesday, August 7, 2019 4:45 AM >>>> To: Andrew Rybchenko >>>> Cc: Pavan Nikhilesh Bhagavatula ; Hemant >>>> Agrawal ; Jerin Jacob Kollanukkaran >>>> ; dev@dpdk.org >>>> Subject: [EXT] Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload >>>> >>>> On Tue, 6 Aug 2019 12:06:35 +0300 >>>> Andrew Rybchenko wrote: >>>> >>>>> On 8/6/19 11:47 AM, Pavan Nikhilesh Bhagavatula wrote: >>>>>>> -----Original Message----- >>>>>>> From: Hemant Agrawal >>>>>>> Sent: Tuesday, August 6, 2019 1:49 PM >>>>>>> To: Pavan Nikhilesh Bhagavatula ; Jerin >>>>>>> Jacob Kollanukkaran >>>>>>> Cc: dev@dpdk.org >>>>>>> Subject: RE: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload >>>>>>>> Add PTYPE to DEV_RX_OFFLOAD_* flags. >>>>>>>> >>>>>>>> Currently, most of the NICs already support PTYPE parsing and >>>>>>>> update >>>>>>> the >>>>>>>> mbuf->packet_type through an internal lookup table, but there is >>>>>>>> mbuf->no >>>>>>> way to >>>>>>>> disable the lookup if the application is not intrested in ptypes >>>>>>> returned by >>>>>>>> `rte_eth_dev_get_supported_ptypes`. >>>>>>>> >>>>>>> [Hemant] it will also mean introducing another check in datapath, >>>>>>> if the application has asked for PTYPE offload - copy the results >>>>>>> to mbuf- >>>>>>>> packet_type otherwise don't do it. >>>>>> I think that having the check would give better performance than >>>>>> loading ptype table to L1 doing a lookup and copying it to mbuf when the >>>> application doesn't need it. >>>>> Anyway, if PMD decides that it is better to always provide packet type >>>>> information - there is no harm. Basically if the offload is not >>>>> requested it makes packet_type undefined in mbuf. >>>>> >>>>>>> Your second patch is incomplete in the sense that it only adds the >>>>>>> capability. But it does not disable the lookups? >>>>>> It is upto the maintainer of the PMD to disable the lookup in data >>>>>> path. If there is a scope of optimization then they could do it. There is no >>>> harm in exposing PTYPE even RX_OFFLOAD_PTYPE is not enabled. >>>>>> I was hesitant to touch data path as it would be impossible to verify >>>> performance effect on all NICs. >>>>> I think it is the right way to approach it especially taking >>>>> transition into account. >>>>> >>>> With hardline API policy, this has to fail on compile for old applications. >> >> Stephen, could you explain a bit more why. > > Existing releases packets will be received with ptype for hardware that > supports it. We should not require users to change their application to > continue to get mbufs with ptype. If your change would break that, and > require application to change; then your change should break the API in > a hard way that causes compile rather than runtime failure. Many thanks, I got it. > The best solution would be to just keep old applications running and compiling > without breaking anything. That means ptype should still be received. > > If (as an optimization) you want to allow application to turn of getting > ptype; then that would be a useful. Probably best done at the port level > as part of configuration. I see, but it contradicts to the existing practice that offloads should be disabled by default and a way to enable should be provided. May be techboard should discuss it and make a decision (covering RSS hash information and Rx mark mentioned in my review notes). >>> Not specific to this API change. That's is the propriety any new symbol addition >>> to the code base. >>> >>> Planning to make this API change available fromv19.11 LTS. >> >> The only way to to require applications to enable PTYPE offload to get >> ptypes in mbuf since 19.11 LTS is to have deprecation notice in 19.08. >> >>>> You can't magically assume that applications using ptype will set new feature. >>> When OFFLOAD flags got introduced, we decided to disable all offloads by default. >>> So, need to add positive logic here to enable offload instead of enable something by >>> Default and disable if required to get have synergy with other offloads. >>> >>> Will update the release note as usual to document the change. >>> Since there is NO ABI change, IMO, we don't need deprecation notice. >> >> Sorry, but it is a behaviour change. Before an application does not need >> to enable ptype offload, but now it is required. It means that application >> will be broken and, therefore, it requires deprecation notice. > > The DPDK development community has to make not breaking applications > a higher priority than adding marginal enhancements Fair, but where is marginal enhancements boundary?