Re: ethdev: hide internal structures

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Tue, Nov 16, 2021 at 03:22:01PM -0800, Stephen Hemminger wrote:
> On Tue, 16 Nov 2021 14:58:08 -0800
> Tyler Retzlaff <roretzla@linux.microsoft.com> 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).