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