From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A19B7C43331 for ; Fri, 6 Sep 2019 14:00:59 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 587D620692 for ; Fri, 6 Sep 2019 14:00:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 587D620692 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5E25A1F407; Fri, 6 Sep 2019 16:00:58 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 056F51F3DE for ; Fri, 6 Sep 2019 16:00:56 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2019 07:00:55 -0700 X-IronPort-AV: E=Sophos;i="5.64,473,1559545200"; d="scan'208";a="177645468" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.95.123]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2019 07:00:54 -0700 Date: Fri, 6 Sep 2019 15:00:51 +0100 From: Bruce Richardson To: Marcin Zapolski Cc: dev@dpdk.org, jerinj@marvell.com Message-ID: <20190906140051.GA1608@bricha3-MOBL.ger.corp.intel.com> References: <20190730124950.1293-1-marcinx.a.zapolski@intel.com> <20190906131813.1343-1-marcinx.a.zapolski@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190906131813.1343-1-marcinx.a.zapolski@intel.com> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [RFC 19.11 v2 0/3] Hide DPDK internal struct from public API 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 Fri, Sep 06, 2019 at 03:18:10PM +0200, Marcin Zapolski wrote: > Several DPDK internal structures are exposed to direct access by user > applications. This patch removes them from public API, and makes core DPDK > functions that use them non-inline. > > v2: > This patch set no longer makes internal DPDK functions non-inline. Instead > it splits the rte_eth_dev structure to private and public part and modifies > function arguments of rx and tx functions. This should bring less performance > impact, but at the cost of needing to modify every PMD to use new rx and tx > functions. > For testing purposes, the ixgbe and i40e drivers are modified to acommodate for > the changes. > > Marcin Zapolski (3): > ethdev: hide key ethdev structures from public API > i40e: make driver compatible with changes in ethdev > ixgbe: make driver compatible with changes in ethdev > Thanks for testing this out Marcin. The performance impact seems lower alright. The amount of changes needed I still am not particularly happy about, so I'd like to propose a third option for consideration. How about leaving the existing inline functions as they are, but also providing the uninline functions for backward compatibility, with a build-time switch to select between the two? Standard builds could use the uninline versions for API/ABI compatibility, while any builds which absolutely need the most performance can switch to using the inline versions at the cost of compatibility. We could even make the build-switch generic to indicate across all components a preference for absolute performance over compatibility. Regards, /Bruce