Thomas, First and easy answer: it is open source, so anyone can recompile. So, what's the issue?
> Without a concept of stable interfaces, it will be difficult to > package and distribute RTE libraries, PMD, and DPDK applications. Right > now, the obvious path would include packaging the PMD bits together > with each DPDK application depending on the version of DPDK the binary > was compiled against. This is clearly not ideal. > >> I agree that some areas could be improved since they are not into the >> critical datapath of packets, but still other areas remain very CPU >> constraints. For instance: >> http://dpdk.org/browse/dpdk/commit/lib/librte_ether/rte_ethdev.h?id=c3d0564cf0f00c3c9a61cf72bd4bd1c441740637 >> >> is bad: >> struct eth_dev_ops >> is churned, no comment, and a #ifdef that changes the structure >> according to compilation! > > This is a very good example as it outlines the difference between > control structures and the fast path. We have this same exact trade off > in the kernel a lot where we have highly optimized internal APIs > towards modules and drivers but want to provide binary compatibility to > a certain extend. As long as we agree on this limited scope, we'll think about it and provide a proposal on dev at dpdk.org mailing list. > As for the specific example you mention, it is relatively trivial to > make eth_dev_ops backwards compatible by appending appropriate padding > to the struct before a new major release and ensure that new members > are added by replacing the padding accordingly. Obviously no ifdefs > would be allowed anymore. Of course, it is basic C! >> Should an application use the librte libraries of the DPDK: >> - you can use RTE_VERSION and RTE_VERSION_NUM : >> http://dpdk.org/doc/api/rte__version_8h.html#a8775053b0f721b9fa0457494cfbb7ed9 > > Right. This would be more or less identical to requiring a specific > DPDK version in OVS_CHEC_DPDK. It's not ideal to require application to > clutter their code with #ifdefs all over for every new minor release > though. > >> - you can write your own wrapper (with CPU overhead) in order to have >> a stable ABI, that wrapper should be tight to the versions of the librte >> => the overhead is part of your application instead of the DPDK, >> - *otherwise recompile your software, it is opensource, what's the >> issue?* >> >> We are opened to any suggestion to have stable ABI, but it should never >> remove the options to have fast/efficient/compilation/CPU execution >> processing. > > Absolutely agreed. We also don't want to add tons of abstraction and > overcomplicate everything. Still, I strongly believe that the definition > of stable interfaces towards applications and especially PMD is > essential. > > I'm not proposing to standardize all the APIs towards applications on > the level of POSIX. DPDK is in early stages and disruptive changes will > come along. What I would propose on an abstract level is: > > 1. Extend but not break API between minor releases. Postpone API > breakages to the next major release. High cadence of major > releases initially, lower cadence as DPDK matures. > > 2. Define ABI stability towards PMD for minor releases to allow > isolated packaging of PMD by padding control structures and keeping > functions ABI stable. I get lost: do you mean ABI + API toward the PMDs or towards the applications using the librte ? Best regards, Vincent