From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3042CA0C41; Wed, 17 Nov 2021 23:05:21 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A058E4068C; Wed, 17 Nov 2021 23:05:20 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id BA16040687 for ; Wed, 17 Nov 2021 23:05:19 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id C730C20C63DC; Wed, 17 Nov 2021 14:05:18 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com C730C20C63DC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1637186718; bh=WZScoD2JVEGMJrWQ+iqrvBShs6cL7x/44jsEcuVN41M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lLtMU2YGVKVP0P78Ws6K3wFkkmD24IhmEDFDqSTin19mf6chVDdr/Pv2fmMut1L0U vXiP4riB0kIlWLbIygs/agDj1r8BgNd4XjJpKjvRDFO/LKssaN27tjDxw2XV71ugsi V9dHkqBgoBtdxFXkXdoWN/TkqzRBtfB1HV1DovnY= Date: Wed, 17 Nov 2021 14:05:18 -0800 From: Tyler Retzlaff To: Stephen Hemminger Cc: "Ananyev, Konstantin" , "dev@dpdk.org" Subject: Re: ethdev: hide internal structures Message-ID: <20211117220518.GA6772@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20211116002440.GA17166@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20211116191018.GA31070@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20211116132510.49731a0c@hermes.local> <20211116225808.GA27960@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20211116152201.2bd1b0da@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211116152201.2bd1b0da@hermes.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Nov 16, 2021 at 03:22:01PM -0800, Stephen Hemminger wrote: > On Tue, 16 Nov 2021 14:58:08 -0800 > Tyler Retzlaff wrote: > > > > > > > Keep a array in application? Portid is universally > > > available. > > > > > > struct my_portdata *my_ports[RTE_ETH_MAXPORTS]; > > > > i guess by this you mean maintain the storage in the application and > > then export that storage for proprietary use in the pmd. ordinarily i > > wouldn't want to have this hard-coded into the modules abi but since > > we are talking about vendor extensions it has to be managed somewhere. > > > > anyway, i guess i have my answer. > > > > thanks stephen, appreciate it. > > Don't understand, how are application and pmd exchanging extra data? > Maybe a non-standard PMD API? yes. consider the case of a "vendor extension" where for a specific pmd driver it is possible that extra / non-standard operations are supported. in this instance we have a pmd that does some whiz-bang thing that isn't something most hardware/pmds could do (or need to under ordinary circumstances) so it doesn't make sense to adapt the generalized pmd api for some one-off hardware/device. however, the vendor ships an application that is extended to understand this extra functionality and needs a way to hook up with and inter-operate with the non-standard api. one example that is very common is some kind of advanced statistics that most hardware aren't capable of producing. as long as the application knows it is working with this advanced hardware it can present those statistics. in the code i'm looking at it isn't statistics but specialized control operations that can't be expressed via the exported pmd api (and should not be).