From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 4DBED2617 for ; Thu, 30 Jun 2016 13:40:22 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id f126so217994996wma.1 for ; Thu, 30 Jun 2016 04:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=mh/ndyTpwYvDxjZlSfZS0cRNVU2qd7OlDBmZFNy+XWE=; b=wcOrv4zIjh3FmPEv5nz054BsHD94P7wx0ZZn7PEECzRtltYKor4QVqv2l3Sq89hKHi JdglST5KkWrfQTHDk6nwItI4MUeWcQNbhJf5a1pffyoEf+shMRYC819hZgnu7vVbiUrY CvTfg4h05GEObQSQEL/Bj1uD0mf+HMIzHsD7e6K+OuTxVJAPothoZEPwRO/AyPOl+O+6 iN/5+Jj3zqxGzud9HZJyXX1zGv6aK+i81rX42MsFOCT+CKa1LXdmojLgWJtuPJZ88Tzq 0MZ7vpaA/hcsjgeziEQU9N0QGpEe1KibFIkYgHGktq2u/Qv30O2gFZ4XVmQ0MJUViWa3 A1IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=mh/ndyTpwYvDxjZlSfZS0cRNVU2qd7OlDBmZFNy+XWE=; b=hnL1DAYTPc21ySpWDiznHR81LnOSOO0LMK/8YlQyIQ32rpk1X8RRsTKQyppECvKzrH zNg9Oq0PjjB2SyrTSDD2LUIQ+vrqdLT/t/1uYSavI5KL8iWo4vNbCSUV/RXnS4hHu+T4 IEHkjeXmAGfhvIqFdC58Vq8Pk3EFeE72AJzNNNS2axBEN6SkBqL6aE6ruljg6yGBhMao IkTi9tJdPZ5taANS1qGEQf1v21sKBJexmz/zvLAX3u3y3wdwKUkms89EKuzC5yKk43oo ViQUyNpDFvZrS5KbY7Ik/iM6ZqursmQeyIbI0NSUizt5zWLrPmc/71gwt6JXL1JTD5WP K/2A== X-Gm-Message-State: ALyK8tLKMl8NNGSh1bgh6imUoh3ksMi9aPWVcU28EVduISB0EK7V6yUnUWGaW/pVE9eBtPCe X-Received: by 10.194.22.169 with SMTP id e9mr13406401wjf.128.1467286822111; Thu, 30 Jun 2016 04:40:22 -0700 (PDT) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id r190sm3994566wme.17.2016.06.30.04.40.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jun 2016 04:40:21 -0700 (PDT) From: Thomas Monjalon To: "Mcnamara, John" Cc: Panu Matilainen , Yuanhan Liu , dev@dpdk.org, "Xie, Huawei" , Rich Lane , Tetsuya Mukawa Date: Thu, 30 Jun 2016 13:40:17 +0200 Message-ID: <1845205.vF3ufAigQM@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1463117111-27050-1-git-send-email-yuanhan.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 11:40:22 -0000 2016-06-30 11:15, Mcnamara, John: > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen > > On 06/30/2016 10:57 AM, Yuanhan Liu wrote: > > > 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. > > > > Awesome! > > > > With that, hopefully others will see the light and follow its example. > > If nothing else, they ought to get a bit envious when you can add features > > left and right without ever having to wait for API/ABI break periods etc > > ;) > > Agreed. We should be doing more of this type of refactoring work to make the API/ABI less easier to break. +1 But we must check the possible performance degradation with care :)