From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 0725C3B5 for ; Thu, 30 Jun 2016 09:39:50 +0200 (CEST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D8F5F8553D; Thu, 30 Jun 2016 07:39:47 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-5-182.ams2.redhat.com [10.36.5.182]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5U7djCI021485; Thu, 30 Jun 2016 03:39:46 -0400 To: Yuanhan Liu , dev@dpdk.org References: <1463117111-27050-1-git-send-email-yuanhan.liu@linux.intel.com> <1465271530-27878-1-git-send-email-yuanhan.liu@linux.intel.com> Cc: huawei.xie@intel.com, Thomas Monjalon , Traynor Kevin , Rich Lane , Tetsuya Mukawa From: Panu Matilainen Message-ID: <2add15af-5323-1f0c-b057-e29eeefb94c3@redhat.com> Date: Thu, 30 Jun 2016 10:39:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1465271530-27878-1-git-send-email-yuanhan.liu@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 30 Jun 2016 07:39:48 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v3 00/20] vhost ABI/API refactoring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 07:39:50 -0000 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! 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. 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 :) Thanks again, - Panu -