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 CF7CDA0613 for ; Thu, 26 Sep 2019 13:52:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 99FC23237; Thu, 26 Sep 2019 13:52:36 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id A6E162D13 for ; Thu, 26 Sep 2019 13:52:34 +0200 (CEST) Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0A8DAC0546FB for ; Thu, 26 Sep 2019 11:52:34 +0000 (UTC) Received: by mail-vk1-f198.google.com with SMTP id q5so916170vkg.20 for ; Thu, 26 Sep 2019 04:52:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1vJUxxgL0fLkMONNij4Jq6I9uGPhwmcH6nr3dqvs4Mk=; b=ZBnYc0qA6eZfpawA8wvyHE9wEFF3TijV45rH7NTDtUXIHm6aH+1ga68C8IC3Dcwr84 ktibLin8HPsFxPqaLEBufRVCmcmrXrBuWLudOm8rLGEuwM7IDMgmQIthCLU2id35XBUp lKwf0iHdciszLj/rP31QT6x7aGmZQTJPx8jnoej83a/SqIaHbLm12Gep43zkyTxupYZP 60/Ajcf6QuWqzbyO5p3UUFgukWqjJUXtCUQf7dxp9SyfbCspjoBRhFgGJNLXagrztMiE 9VJFAc52jQhztgZsMDcx1Tpdg6gmop3/lwOQnlIJQmwf90c0cpyT8ISFndfGBsz0LZ4X ob3w== X-Gm-Message-State: APjAAAVzfiTlQDx2f11ABScj3i9LT2NndEQ2tQp7Df4rg2p/e5iV3bQg a4FeDtRFY0mxAPk4Aaxzd5mEazVyEWjZI9FI/S5mw3UEO9zqEbf8yY1RfzU6RXvXjkUk9//Nw4W /X7qN/yUSNMfpykpZP4o= X-Received: by 2002:a1f:1897:: with SMTP id 145mr1366236vky.53.1569498753135; Thu, 26 Sep 2019 04:52:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqzUeM4qimJ+blz+47tZWqKCWP/AkD5F9PL8fKe8nzOq+hzje1SVm65PLSEjY2RyuLtGJ6tBJV/71qBVtBg4g/8= X-Received: by 2002:a1f:1897:: with SMTP id 145mr1366210vky.53.1569498752803; Thu, 26 Sep 2019 04:52:32 -0700 (PDT) MIME-Version: 1.0 References: <980083c6-130a-9658-f82b-0c9ddc7cc0cc@ashroe.eu> <2601191342CEEE43887BDE71AB9772580191969C2E@irsmsx105.ger.corp.intel.com> <90610982-ac3e-314e-a623-81610e591958@solarflare.com> In-Reply-To: From: David Marchand Date: Thu, 26 Sep 2019 13:52:21 +0200 Message-ID: To: Andrew Rybchenko , Thomas Monjalon Cc: "Ananyev, Konstantin" , Jerin Jacob , Ray Kinsella , dpdk-dev , "Richardson, Bruce" , Jerin Jacob Kollanukkaran , Hemant Agrawal , Stephen Hemminger , "Yigit, Ferruh" , "maxime.coquelin@redhat.com" , "Zapolski, MarcinX A" , Ian Stokes , Ilya Maximets Content-Type: text/plain; charset="UTF-8" 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" Fixed Ilya address. On Thu, Sep 26, 2019 at 1:50 PM David Marchand wrote: > > On Thu, Sep 26, 2019 at 1:13 PM Andrew Rybchenko > wrote: > > > > 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. > > Did we ensure that external users have all the required api before > hiding the rte_eth_dev struct? > ovs still accesses rte_eth_devices[]. > > CC Ian and Ilya. -- David Marchand