[dpdk-dev] [ovs-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports.
vincent.jardin at 6wind.com
Wed Jan 29 17:34:46 CET 2014
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:
>> 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 :
> 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
>> - 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
>> We are opened to any suggestion to have stable ABI, but it should never
>> remove the options to have fast/efficient/compilation/CPU execution
> 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
> 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 ?
More information about the dev