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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 5AB5DC3A5A2 for ; Tue, 10 Sep 2019 12:20:07 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id DAD01208E4 for ; Tue, 10 Sep 2019 12:20:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DAD01208E4 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 A45BA1EC7D; Tue, 10 Sep 2019 14:20:04 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 0CC001EC6A for ; Tue, 10 Sep 2019 14:20:02 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2019 05:19:56 -0700 X-IronPort-AV: E=Sophos;i="5.64,489,1559545200"; d="scan'208";a="268391626" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.46]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2019 05:19:55 -0700 Date: Tue, 10 Sep 2019 13:19:52 +0100 From: Bruce Richardson To: "Zapolski, MarcinX A" Cc: "dev@dpdk.org" Message-ID: <20190910121952.GA1898@bricha3-MOBL.ger.corp.intel.com> References: <20190730124950.1293-1-marcinx.a.zapolski@intel.com> <20190906131813.1343-2-marcinx.a.zapolski@intel.com> <51FEE37A1339864DB0A4E34597F561E30D5D6FCC@HASMSX113.ger.corp.intel.com> <20190910100659.GA1894@bricha3-MOBL.ger.corp.intel.com> <51FEE37A1339864DB0A4E34597F561E30D5D6FFB@HASMSX113.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51FEE37A1339864DB0A4E34597F561E30D5D6FFB@HASMSX113.ger.corp.intel.com> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [RFC 19.11 v2 1/3] ethdev: hide key ethdev structures 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 Tue, Sep 10, 2019 at 11:13:50AM +0100, Zapolski, MarcinX A wrote: > > -----Original Message----- > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > Sent: Tuesday, September 10, 2019 12:07 PM > > To: Zapolski, MarcinX A > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [RFC 19.11 v2 1/3] ethdev: hide key ethdev > > structures from public API > > > > On Tue, Sep 10, 2019 at 09:59:51AM +0000, Zapolski, MarcinX A wrote: > > > <...> > > > > @@ -3994,7 +4054,55 @@ void * > > > > rte_eth_dev_get_sec_ctx(uint16_t port_id); > > > > > > > > > > > > -#include > > > > +struct rte_eth_dev_callback; > > > > +/** Structure to keep track of registered callbacks */ > > > > +TAILQ_HEAD(rte_eth_dev_cb_list, rte_eth_dev_callback); > > > > + > > > > +/** > > > > + * Structure used to hold information about the callbacks to be > > > > +called for a > > > > + * queue on RX and TX. > > > > + */ > > > > +struct rte_eth_rxtx_callback { > > > > + struct rte_eth_rxtx_callback *next; > > > > + union{ > > > > + rte_rx_callback_fn rx; > > > > + rte_tx_callback_fn tx; > > > > + } fn; > > > > + void *param; > > > > +}; > > > > + > > > > +/** > > > > + * The generic data structure associated with each ethernet device. > > > > + * > > > > + * Pointers to burst-oriented packet receive and transmit functions > > > > +are > > > > + * located at the beginning of the structure, along with the > > > > +pointer to > > > > + * where all the data elements for the particular device are stored > > > > +in shared > > > > + * memory. This split allows the function pointer and driver data > > > > +to be per- > > > > + * process, while the actual configuration data for the device is shared. > > > > + */ > > > I would like to raise one more concern (maybe not the smartest thing > > > to do involving my own patch, but I will sleep better when this is resolved). > > > Does anyone know what the author of this comment had in mind? I could > > > not find any code that utilizes this split, and this patch clearly > > > breaks it. If it is obsolete, I guess this comment could be removed. > > > > As the comment suggest the split is for multi-process suport. The data > > structures for the RX/TX queues etc. all need to be common across > > processes, while the function pointers need to be per-process. Originally, in > > very early versions of DPDK there was no rte_eth_dev_data structure, all > > fields - both data and function pointers - were in rte_eth_dev itself. > > > > /Bruce > > Yes, I see the need to have the elements separated. But the comment suggests > that the order of variables in structure is important. I just want to make > sure that it is not. I don't believe it's particularly significant. The main thing was to ensure that we kept the fast-path accessed data on the same cacheline.