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 d...@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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
