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 D86C5A0554; Tue, 18 Feb 2020 07:01:18 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 256F61D9FE; Tue, 18 Feb 2020 07:01:18 +0100 (CET) Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by dpdk.org (Postfix) with ESMTP id 598701D9FD for ; Tue, 18 Feb 2020 07:01:16 +0100 (CET) Received: by mail-pl1-f196.google.com with SMTP id e8so7626657plt.9 for ; Mon, 17 Feb 2020 22:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=REUGBLw9oi+0ukQJdLApkk3AtuDpmh8I2tmA9fOUx3E=; b=Eimv0Ne5fQIAr1w7uaL4Bt7QLcLjIppTCLYQ3NJvz4F5Ml8pVbKQYKDgu3+TBnTzTd 1o7YAVo2nUijI8GCxPDU/HjyQyce9kTIMO06+gMuzyLAfgi6yusehuxb89RyKriuZQzt QoCjyKhzbUHkdJo4vtzEqUmlJdysm3CP4NiIld1xeZmo2/C8LrDRGORvb4mxbu8Hkn4w qqkbv6bz7FkfUzP/cFo5kSLsi1t7LNVtDXAnCw4H4N7BMI3bFJPObz4xET4cMnHWmcUq 0kJJ5auSs02nYwP2lrkdTfwrR29rKJjjUlOu8SsE+oIAu81t1X/1MaYcZ4urn7Gp9gyx c5bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=REUGBLw9oi+0ukQJdLApkk3AtuDpmh8I2tmA9fOUx3E=; b=OmKhw4kYeWiIw4pzTNzGsEiZ58JKZnqO4Z2WfySCxRha1qiABXNdDAaxGkZvUd1cxa A71fpyqsEMMMT3ZGIfac3dQdPLkJ+PsA5gcRcXhpGt6+mKr8kl8aLd/5u3TXcSHWXpY2 /6n4bnWr0oT+VCKrl0Jah9I4iju33rVxM79ug8jgMOJ0Af0XsRFaQi4HVb/5CXF3Qm9y VuNYOmI5Uo6sZFnOQTTmmo99s9q1V72G8sZdFGPaR9lhl/CG68rtKfXQE/gi/qs/y6Mt 7BhmJxA17CGz38Aj2F+5fZ9LpA8fbv3lbxnHlnr5SgNUD9mvhoYxJA8fjC6cnr55JAad Nmhw== X-Gm-Message-State: APjAAAW8cFpTHSJL+q6vMey4sTFoLup03OQ6JmuGL9/AxfGoOXStcljO tYYTneu/Vbz8lUiUllAUWpkCOw== X-Google-Smtp-Source: APXvYqwo8AT6bcHKvb3MQZEssqjefY9qlZjXiLSov4W9JiPuhTwNXqTBjtqowjgN5bPRpSM5k62Yww== X-Received: by 2002:a17:902:6508:: with SMTP id b8mr19312127plk.201.1582005675523; Mon, 17 Feb 2020 22:01:15 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id u26sm2294757pfn.46.2020.02.17.22.01.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Feb 2020 22:01:15 -0800 (PST) Date: Mon, 17 Feb 2020 22:01:06 -0800 From: Stephen Hemminger To: Ferruh Yigit Cc: Neil Horman , John McNamara , Marko Kovacevic , dev@dpdk.org, David Marchand , Thomas Monjalon , Andrew Rybchenko Message-ID: <20200217220106.25ceb64c@hermes.lan> In-Reply-To: <20200217153805.888130-1-ferruh.yigit@intel.com> References: <20200217153805.888130-1-ferruh.yigit@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] doc: plan splitting the ethdev ops struct 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, 17 Feb 2020 15:38:05 +0000 Ferruh Yigit wrote: > For the ABI compatibility it is better to hide internal data structures > from the application as much as possible. But because of some inline > functions 'struct eth_dev_ops' can't be hidden completely. > > Plan is to split the 'struct eth_dev_ops' into two as ones used by > inline functions and ones not used, and hide the second part that not > used by inline functions completely to the application. > > Signed-off-by: Ferruh Yigit > --- > Cc: David Marchand > Cc: Thomas Monjalon > Cc: Andrew Rybchenko > --- > doc/guides/rel_notes/deprecation.rst | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > index dfcca87ab..2aa431028 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -72,6 +72,12 @@ Deprecation Notices > In 19.11 PMDs will still update the field even when the offload is not > enabled. > > +* ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as possible. > + Currently the ``struct eth_dev_ops`` struct is accessible by the application > + because some inline functions, like ``rte_eth_tx_descriptor_status()``, > + access the struct directly. The struct will be separate in two, the ops used > + by inline functions still will be accessible to user but rest will be hidden. > + > * cryptodev: support for using IV with all sizes is added, J0 still can > be used but only when IV length in following structs ``rte_crypto_auth_xform``, > ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal Good luck, truely hiding internals is hard. The mbuf structure is already split but not really hidden at all (just look at dwarf output). It doesn't make sense to do it unless you can really hide it. I would attack the rte_device stuff first. Make rte_device opaque to the application that would help for future versions. Then work backwards to rte_tehtdev.