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 70432A0613 for ; Tue, 24 Sep 2019 18:42:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1EAA92C38; Tue, 24 Sep 2019 18:42:31 +0200 (CEST) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 28CC02BEA for ; Tue, 24 Sep 2019 18:42:29 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id h144so6044909iof.7 for ; Tue, 24 Sep 2019 09:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+K62vVjNgNt+aKzjOsosVwdSh5q7gRb2RexdqufTC2E=; b=B0mN1Z77hHHqS/iwb9sosfeNvd2nbwr910QpIGRk2lrTHXm0Sn1m3wDI4FubafcPPF yq7uo6udzEL4tqGrq3TpSzLoXE0ntXP+ASYwNOlkDZ5iqBzVDyvuSHcoX7P4rujMrpJX D2S9W4icFkY4s0nKsw+IlcqdB+3E4yB3voUSBV+XLR1lSQbJ1mdsJe0/xcHCY9Ewu3qw VkPVPwN3vozQ4O/yB4+pQ8wj2zsqImjLiEpAutMgPHCYJuPSuCSQieE64rEkJ8FI+tbh g3jVmJZnOshaFrFYkeMS2j+Xnfq9dhrt38EocDNsUTN0mmruGS8O97FpgI1o+JOJjASY tr8A== 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=+K62vVjNgNt+aKzjOsosVwdSh5q7gRb2RexdqufTC2E=; b=LZNM2imUGQGsNxzSTJp+ZrY+03YpVM+VO+QOWBlB6lc306GNEdOwlWEPhollxP3AnT y5eiG5ba1K77gHeUwjbkjtmzOW2MtDMgNU8ZIbXV9mXtR68nXGi+AMiylsO4F2xjY/fr LBhnXULwJcfX1UGvHW+Ugb67CL+15QfIKwR/bDq88Teq+ZOGWUk/svULvLyPnaOXQ+VQ 1yUkaI5jtCkJqKjsilDc2OwMoSF5A/F6zxVGWXc676qts6IDImPzUSXcaxx6gKBx/L1Z IOI7yguYfWqTYRvcutCbbiBePZNz7YmTY6baUVnvYPBpz1Abp7tSTnkItO/0ZzLN/VFt 2cNw== X-Gm-Message-State: APjAAAXjm+3uQJqjY1WIsd0Qk7Q/opNPM2sX2AzATTMo1qDVH4VQ4Q9M 3+xWMTW6ApTdoJkArHsUJibSgT9uKqB7XBGa1L4= X-Google-Smtp-Source: APXvYqw/ctIGGhgyMjj2UshfDrByLBz1KgBLsIRwVtgyCxsdVA4pbshBDZbadUgvKUfHsVdTZtlFCL6Ubo2PBxXn2Gg= X-Received: by 2002:a6b:c895:: with SMTP id y143mr4316687iof.271.1569343348356; Tue, 24 Sep 2019 09:42:28 -0700 (PDT) MIME-Version: 1.0 References: <980083c6-130a-9658-f82b-0c9ddc7cc0cc@ashroe.eu> In-Reply-To: <980083c6-130a-9658-f82b-0c9ddc7cc0cc@ashroe.eu> From: Jerin Jacob Date: Tue, 24 Sep 2019 22:12:16 +0530 Message-ID: To: Ray Kinsella Cc: dpdk-dev , "Richardson, Bruce" , Jerin Jacob Kollanukkaran , Hemant Agrawal , Thomas Monjalon , Stephen Hemminger , "Yigit, Ferruh" , "Ananyev, Konstantin" , maxime.coquelin@redhat.com, David Marchand , Marcin Zapolski 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" On Mon, Sep 23, 2019 at 9:49 PM Ray Kinsella wrote: > > 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. > > Thanks, > > Ray K