> > > Acked-by: Bruce Richardson <[email protected]> > > > > > > Given where we are, this is probably a reasonable solution. > However, I'm > > > also thinking that maybe we should have a discussion as to whether > testpmd > > > - which is, after all, for testing PMDs - should be limited to the > public > > > APIs. Is there not a case to be made for allowing the per-driver > testpmd > > > files to access the internals of the driver for testing purposes? > > > > > +techboard and others for more input and thoughts for the future. > > Accessing some symbols from the internal ABI is probably ok but it is > a slippery topic. > Like the ethdev ops changes between 25.11/26.07 that triggered crashes > in app/test.
I tend to agree with Bruce's statement about the purpose of testpmd: The purpose of testpmd is testing PMDs. When used for PMD development purposes, this means: 1. Testpmd should be allowed to go deep inside PMDs. 2. Testpmd should not be limited by ABI/API stability. This also means that the testpmd released with DPDK 27.03 is not expected to be compatible with the DPDK 26.11 LTS runtime. If a new release of testpmd offers new features, they will not be available until you upgrade your DPDK runtime. "Nice to have": When used for non-PMD development purposes, perhaps testpmd could emit a warning if not running on the same build as the DPDK runtime. -Morten
