Message ID | 1459925635-15299-1-git-send-email-yuanhan.liu@linux.intel.com (mailing list archive) |
---|---|
State | Accepted, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id A1B282C62; Wed, 6 Apr 2016 08:52:20 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 8A2D82C5A for <dev@dpdk.org>; Wed, 6 Apr 2016 08:52:18 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP; 05 Apr 2016 23:52:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,447,1455004800"; d="scan'208";a="949053434" Received: from yliu-dev.sh.intel.com ([10.239.67.191]) by orsmga002.jf.intel.com with ESMTP; 05 Apr 2016 23:52:16 -0700 From: Yuanhan Liu <yuanhan.liu@linux.intel.com> To: dev@dpdk.org Cc: huawei.xie@intel.com, Thomas Monjalon <thomas.monjalon@6wind.com>, Yuanhan Liu <yuanhan.liu@linux.intel.com>, Ilya Maximets <i.maximets@samsung.com> Date: Wed, 6 Apr 2016 14:53:55 +0800 Message-Id: <1459925635-15299-1-git-send-email-yuanhan.liu@linux.intel.com> X-Mailer: git-send-email 1.9.0 Subject: [dpdk-dev] [PATCH] vhost: ABI/API change announcement due to refactor X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Yuanhan Liu
April 6, 2016, 6:53 a.m. UTC
We currently exposed way too many fields (or even structures) than
necessary. For example, vhost_virtqueue struct should NOT be exposed
to user at all: application just need to tell the right queue id to
locate a specific queue, and that's all. Instead, the structure should
be defined in an internal header file. With that, we could do any changes
to it we want, without worrying about that we may offense the painful
ABI rules.
Similar changes could be done to virtio_net struct as well, just exposing
very few fields that are necessary and moving all others to an internal
structure.
Huawei then suggested a more radical yet much cleaner one: just exposing
a virtio_net handle to application, just like the way kernel exposes an
fd to user for locating a specific file, and exposing some new functions
to access those old fields, such as flags, virt_qp_nb.
With this change, we're likely to be free from ABI violations forever
(well, except when we have to extend the virtio_net_device_ops struct).
For example, following nice cleanup would not be a blocking one then:
http://dpdk.org/ml/archives/dev/2016-February/033528.html
Suggested-by: Huawei Xie <huawei.xie@intel.com>
Cc: Ilya Maximets <i.maximets@samsung.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
doc/guides/rel_notes/deprecation.rst | 7 +++++++
1 file changed, 7 insertions(+)
Comments
On 04/06/2016 09:53 AM, Yuanhan Liu wrote: > We currently exposed way too many fields (or even structures) than > necessary. For example, vhost_virtqueue struct should NOT be exposed > to user at all: application just need to tell the right queue id to > locate a specific queue, and that's all. Instead, the structure should > be defined in an internal header file. With that, we could do any changes > to it we want, without worrying about that we may offense the painful > ABI rules. > > Similar changes could be done to virtio_net struct as well, just exposing > very few fields that are necessary and moving all others to an internal > structure. > > Huawei then suggested a more radical yet much cleaner one: just exposing > a virtio_net handle to application, just like the way kernel exposes an > fd to user for locating a specific file, and exposing some new functions > to access those old fields, such as flags, virt_qp_nb. > > With this change, we're likely to be free from ABI violations forever > (well, except when we have to extend the virtio_net_device_ops struct). > For example, following nice cleanup would not be a blocking one then: > > http://dpdk.org/ml/archives/dev/2016-February/033528.html > > Suggested-by: Huawei Xie <huawei.xie@intel.com> > Cc: Ilya Maximets <i.maximets@samsung.com> > Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> > --- > doc/guides/rel_notes/deprecation.rst | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > index ad31355..7d16d86 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -40,3 +40,10 @@ Deprecation Notices > The existing API will be backward compatible, but there will be new API > functions added to facilitate the creation of mempools using an external > handler. The 16.07 release will contain these changes. > + > +* A librte_vhost public structures refactor is planned for DPDK 16.07 > + that requires both ABI and API change. > + The proposed refactor would expose DPDK vhost dev to applications as > + a handle, like the way kernel exposes an fd to user for locating a > + specific file, and to keep all major structures internally, so that > + we are likely to be free from ABI violations in future. > Acked-by: Panu Matilainen <pmatilai@redhat.com> I applaud the initiative, public structs are by far the worst offender when trying to maintain a stable ABI because they're so hard to correctly version that hardly anybody besides glibc bothers. - Panu -
2016-04-07 10:12, Panu Matilainen: > On 04/06/2016 09:53 AM, Yuanhan Liu wrote: > > +* A librte_vhost public structures refactor is planned for DPDK 16.07 > > + that requires both ABI and API change. > > + The proposed refactor would expose DPDK vhost dev to applications as > > + a handle, like the way kernel exposes an fd to user for locating a > > + specific file, and to keep all major structures internally, so that > > + we are likely to be free from ABI violations in future. > > Acked-by: Panu Matilainen <pmatilai@redhat.com> > > I applaud the initiative, public structs are by far the worst offender > when trying to maintain a stable ABI because they're so hard to > correctly version that hardly anybody besides glibc bothers. Yes, nice cleanup to do. Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> > > +* A librte_vhost public structures refactor is planned for DPDK 16.07 > > > + that requires both ABI and API change. > > > + The proposed refactor would expose DPDK vhost dev to applications as > > > + a handle, like the way kernel exposes an fd to user for locating a > > > + specific file, and to keep all major structures internally, so that > > > + we are likely to be free from ABI violations in future. > > > > Acked-by: Panu Matilainen <pmatilai@redhat.com> > > > > I applaud the initiative, public structs are by far the worst offender > > when trying to maintain a stable ABI because they're so hard to > > correctly version that hardly anybody besides glibc bothers. > > Yes, nice cleanup to do. > > Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com> Applied, thanks
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index ad31355..7d16d86 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -40,3 +40,10 @@ Deprecation Notices The existing API will be backward compatible, but there will be new API functions added to facilitate the creation of mempools using an external handler. The 16.07 release will contain these changes. + +* A librte_vhost public structures refactor is planned for DPDK 16.07 + that requires both ABI and API change. + The proposed refactor would expose DPDK vhost dev to applications as + a handle, like the way kernel exposes an fd to user for locating a + specific file, and to keep all major structures internally, so that + we are likely to be free from ABI violations in future.