[dpdk-dev] [ovs-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports.
Vincent JARDIN
vincent.jardin at 6wind.com
Wed Jan 29 11:26:58 CET 2014
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
More information about the dev
mailing list