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 E8351A0613 for ; Thu, 26 Sep 2019 13:13:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 67E3B1BEB5; Thu, 26 Sep 2019 13:13:16 +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 7E8AE1BEB3 for ; Thu, 26 Sep 2019 13:13:15 +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-us4.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 86E31B40079; Thu, 26 Sep 2019 11:13:13 +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; Thu, 26 Sep 2019 12:13:05 +0100 To: "Ananyev, Konstantin" , Jerin Jacob , Ray Kinsella CC: dpdk-dev , "Richardson, Bruce" , Jerin Jacob Kollanukkaran , Hemant Agrawal , Thomas Monjalon , "Stephen Hemminger" , "Yigit, Ferruh" , "maxime.coquelin@redhat.com" , David Marchand , "Zapolski, MarcinX A" References: <980083c6-130a-9658-f82b-0c9ddc7cc0cc@ashroe.eu> <2601191342CEEE43887BDE71AB9772580191969C2E@irsmsx105.ger.corp.intel.com> From: Andrew Rybchenko Message-ID: <90610982-ac3e-314e-a623-81610e591958@solarflare.com> Date: Thu, 26 Sep 2019 14:13:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB9772580191969C2E@irsmsx105.ger.corp.intel.com> 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-24934.003 X-TM-AS-Result: No-14.311800-8.000000-10 X-TMASE-MatchedRID: 9vvqFUF7IWnmLzc6AOD8DfHkpkyUphL9F4T0JlzLSMsW6M2A15L1QHZl 7Z2noCfreLRlxRbWmjuVXjhXSOnI7NA4NqdM7aY0wY28o+cGA5rLRD51bz5RZArkj7klVufutBA nednMe93PgCh0lH02P+5iJI+FR+e+jHHp3pfy0npQUls+WYG/w8V0QyhMrtsxilzcm2p6JE8tVx nmZPjhcbiXDrBj3AYI36qbk6ChnzBKzaNiN7Y92mivjLE8DPtZNrB7jxZ37M75+tteD5Rzhdmaz ryuvYTLf6E9bXJRUQRSPI9d8G7JYzOEYalr+R8F4b5sZaeDVbsMq8t1qGggRBqB+wKK9uZe2EDm 31dWQe8tYiO9Pyav14DlFhTekDhfw785bCYYyVHC0TXpqtexIldEEmf6TRVB7V/Rrd7FCxIiOUa tQ1uezWrU8HSCKLYMeAD6+Iioq9EWljuKwf2EPLgTyrrpk8McmKITilALu13I9EDAP/dpti+qXV u8f4GocDo4qe58ugwKfKbIR71J3JodpHrV7ghHwbRQ2Bpmlio3MuSq9XdO0wwv1ZvdCH+FFXCUe F7nROZFzHrMKRZICh3DeMfpbWC9c8knU5CZtUpxBYLeFmtS7cdtmwbxPlmOtB9ItN9lSLwNQtxL NQ91N/doK1MEIGGXeTjw/FyRX6RNfs8n85Te8oMbH85DUZXyseWplitmp0j+efAnnZBiL0OAfBu /XeE8UdYubSR4HFOkuIPgzm51yNzLuyDjNKM58QNh9IcxKUIbYs/qaanvyJjsg1A0gi+sMw9S97 BLslHIQlQHDC43g+yl7JAgIxLi X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--14.311800-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24934.003 X-MDID: 1569496394-eHT_2QCIY52v 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] RFC: hiding struct rte_eth_dev 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 9/24/19 7:50 PM, Ananyev, Konstantin wrote: > Hi everyone, > >>> Hi folks, >>> >>> The ABI Stability proposals should be pretty well known at this point. >>> The latest rev is here ... >>> >>> http://inbox.dpdk.org/dev/1565864619-17206-1-git-send-email-mdr@ashroe.eu/ >>> >>> As has been discussed public data structure's are risky for ABI >>> stability, as any changes to a data structure can change the ABI. As a >>> general rule you want to expose as few as possible (ideally none), and >>> keep them as small as possible. >>> >>> One of the key data structures in DPDK is `struct rte_eth_dev`. In this >>> case, rte_eth_dev is exposed public-ally, as a side-effect of the >>> inlining of the [rx,tx]_burst functions. >>> >>> Marcin Zapolski has been looking at what to do about it, with no current >>> consensus on a path forward. The options on our table is:- >>> >>> 1. Do nothing, live with the risk to DPDK v20 ABI stability. >>> >>> 2. Pad rte_eth_dev, add some extra bytes to the structure "in case" we >>> need to add a field during the v20 ABI (through to 20.11). >>> >>> 3. Break rte_eth_dev into public and private structs. >>> - See >>> http://inbox.dpdk.org/dev/20190906131813.1343-1-marcinx.a.zapolski@intel.com/ >>> - This ends up quiet an invasive patch, late in the cycle, however it >>> does have no performance penalty. >>> >>> 4. Uninline [rx,tx]_burst functions >>> - See >>> http://inbox.dpdk.org/dev/20190730124950.1293-1-marcinx.a.zapolski@intel.com/ >>> - This has a performance penalty of ~2% with testpmd, impact on a "real >>> workload" is likely to be in the noise. >>> >>> We need to agree an approach for v19.11, and that may be we agree to do >>> nothing. My personal vote is 4. as the simplest with minimal impact. >> My preference NOT to do #4. Reasons are: >> - I have seen performance drop from 1.5% to 3.5% based on the arm64 >> cores in use(Embedded vs Server cores) >> - We need the correct approach to cater to cryptodev and eventdev as >> well. If #4 is checked in, We will >> take shotcut for cryptodev and eventdev >> >> My preference #1, do nothing, is probably ok and could live with #2, >> adding padding, >> and fix properly with #3 as when needed and use #3 scheme for crypto >> dev and eventdev as well. >> >> > My preference would be #4 also. > If that's not an option, then I suppose #1 for 19.11 and #3 for next release > when ABI breakage would be allowed. > BTW, good point that we need similar thing for other dev types too. > Konstantin My preference would be #4 or #1. #2 and #3 are both tradeoffs and do not resolve ABI breaking completely. #3 is really invasive, it requires changes of driverRx/Tx burst prototypes and uninline descriptor status functions (may be it would be better to change callback prototypes as well, but keep functions inline). #4 is better since it is really a step to ABI stability and it still allow to do many generic checks (dev->data dependent) on ethdev API level. Andrew