Hi Thomas, On 29/01/2014 09:15, Thomas Graf wrote:
> The obvious and usual best practise would be for DPDK to guarantee > ABI stability between minor releases. > > Since dpdk-dev is copied as well, any comments? DPDK's ABIs are not Kernel's ABIs, they are not POSIX, there is no standard. Currently, there is no such plan to have a stable ABI since we need to keep freedom to chase CPU cycles over having a stable ABI. For instance, some applications on top of the DPDK process the packets in less than 150 CPU cycles (have a look at testpmd: http://dpdk.org/browse/dpdk/tree/app/test-pmd ) 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! 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 - 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. Best regards, Vincent
