[dpdk-dev] [PATCH v3 00/20] vhost ABI/API refactoring
pmatilai at redhat.com
Thu Jun 30 09:39:45 CEST 2016
On 06/07/2016 06:51 AM, Yuanhan Liu wrote:
> v3: - adapted the new vhost ABI/API changes to tep_term example, to make
> sure not break build at least.
> - bumped the ABI version to 3
> NOTE: I created a branch at dpdk.org  for more conveinient testing:
> : git://dpdk.org/next/dpdk-next-virtio for-testing
> Every time we introduce a new feature to vhost, we are likely to break
> ABI. Moreover, some cleanups (such as the one from Ilya to remove vec_buf
> from vhost_virtqueue struct) also break ABI.
> This patch set is meant to resolve above issue ultimately, by hiding
> virtio_net structure (as well as few others) internaly, and export the
> virtio_net dev strut to applications by a number, vid, like the way
> kernel exposes an fd to user space.
> Back to the patch set, the first part of this set makes some changes to
> vhost example, vhost-pmd and vhost, bit by bit, to remove the dependence
> to "virtio_net" struct. And then do the final change to make the current
> APIs to adapt to using "vid".
> After that, "vrtio_net_device_ops" is the only left open struct that an
> application can acces, therefore, it's the only place that might introduce
> potential ABI breakage in future for extension. Hence, I made few more
> (5) space reservation, to make sure we will not break ABI for a long time,
> and hopefuly, forever.
Been intending to say this for a while but seems I never actually got
around to do so:
This is a really fine example of how to refactor an API against constant
ABI breakages, thank you Yuanhan! Exported structs are one of the
biggest obstacles in keeping a stable ABI while adding new features, and
while its not always possible to hide everything to this extent, the
damage (erm, exposure) can usually be considerably limited by careful
Since the first and the foremost objection against doing this in the
DPDK context is always "but performance!", I'm curious as to what sort
of numbers you're getting with the new API vs the old one? I'm really
hoping other libraries would follow suit after seeing that its possible
to provide a future-proof API/ABI without sacrificing performance :)
- Panu -
More information about the dev