On Thu, Jun 30, 2016 at 10:39:45AM +0300, Panu Matilainen wrote:
> 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 [0] for more conveinient testing:
> >
> > [0]: 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!
Panu, thanks!
> 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 API design.
Agreed.
> 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 :)
>From my (limited) test, nope, I see no performance drop at all, not even a
little.
--yliu
