> -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Thursday, October 14, 2021 4:26 PM > To: Harris, James R <james.r.har...@intel.com>; Walker, Benjamin > <benjamin.wal...@intel.com>; Xia, Chenbo <chenbo....@intel.com> > Cc: Liu, Changpeng <changpeng....@intel.com>; David Marchand > <david.march...@redhat.com>; dev@dpdk.org; Aaron Conole <acon...@redhat.com>; > Zawadzki, Tomasz <tomasz.zawad...@intel.com> > Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs > > 14/10/2021 10:07, Xia, Chenbo: > > From: Thomas Monjalon <tho...@monjalon.net> > > > 14/10/2021 09:00, Xia, Chenbo: > > > > From: Thomas Monjalon <tho...@monjalon.net> > > > > > 14/10/2021 04:21, Xia, Chenbo: > > > > > > From: Thomas Monjalon <tho...@monjalon.net> > > > > > > > Yes I think we need to agree on functions to keep as-is for > > > compatibility. > > > > > > > Waiting for your input please. > > > > > > > > > > > > So, do you mean currently DPDK doesn't guarantee ABI for drivers > > > > > > > > > > Yes > > > > > > > > > > > but could have driver ABI in the future? > > > > > > > > > > I don't think so, not general compatibility, > > > > > but we can think about a way to avoid breaking SPDK specifically, > > > > > which has less requirements. > > > > > > > > So the problem here is exposing some APIs to SPDK directly? Without the > > > 'enable_driver_sdk' > > > > option, I don't see a solution of both exposed and not-ABI. Any idea in > your > > > mind? > > > > > > No the idea is to keep using enable_driver_sdk. > > > But so far, there is no compatibility guarantee for driver SDK. > > > The discussion is about which basic compatibility requirement is needed > for > > > SPDK. > > > > Sorry for not understanding your point quickly, but what's the difference of > > 'general compatibility' and 'basic compatibility'? Because in my mind, one > > struct or function should either be ABI-compatible or not. Could you help > explain > > it a bit? > > I wonder whether we could have a guarantee for a subset of structs and > functions. > Anyway, this is just opening the discussion to collect some inputs first. > Then we'll have to check what is possible and get a techboard approval. >
After going through related code in SPDK, I think we can add some new functions and keep some macros in the exposed header (i.e., rte_bus_pci.h) for SPDK to register pci driver and get needed info. Most structs/marocs will be hided and SPDK can use the new proposed APIs and small set of macros/structs to build. In this way, the problem of SPDK building with DPDK distros and ABI issue can both be solved. APIs like struct rte_pci_device and struct rte_pci_driver can be hided to minimize pci bus ABI. Thomas & SPDK folks, please share your opinions of above. Thanks, Chenbo
