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 675776832 for ; Wed, 29 Jan 2014 12:13:38 +0100 (CET) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0TBEsJw013280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jan 2014 06:14:54 -0500 Received: from lsx.localdomain (vpn1-5-163.ams2.redhat.com [10.36.5.163]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s0TBEpD5013915; Wed, 29 Jan 2014 06:14:52 -0500 Message-ID: <52E8E2AB.1080600@redhat.com> Date: Wed, 29 Jan 2014 12:14:51 +0100 From: Thomas Graf Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Vincent JARDIN References: <1390873715-26714-1-git-send-email-pshelar@nicira.com> <52E7D13B.9020404@redhat.com> <52E8B88A.1070104@redhat.com> <52E8D772.9070302@6wind.com> In-Reply-To: <52E8D772.9070302@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: "dev@openvswitch.org" , dev@dpdk.org, Gerald Rogers , dpdk-ovs@ml01.01.org Subject: Re: [dpdk-dev] [ovs-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports. 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: Wed, 29 Jan 2014 11:13:38 -0000 Vincent, On 01/29/2014 11:26 AM, Vincent JARDIN wrote: > DPDK's ABIs are not Kernel's ABIs, they are not POSIX, there is no > standard. Currently, there is no such plan to have a stable ABI since we > need to keep freedom to chase CPU cycles over having a stable ABI. For > instance, some applications on top of the DPDK process the packets in > less than 150 CPU cycles (have a look at testpmd: > http://dpdk.org/browse/dpdk/tree/app/test-pmd ) I understand the requirement to not introduce overhead with wrappers or shim layers. No problem with that. I believe this is mainly a policy and release process issue. Without a concept of stable interfaces, it will be difficult to package and distribute RTE libraries, PMD, and DPDK applications. Right now, the obvious path would include packaging the PMD bits together with each DPDK application depending on the version of DPDK the binary was compiled against. This is clearly not ideal. > I agree that some areas could be improved since they are not into the > critical datapath of packets, but still other areas remain very CPU > constraints. For instance: > http://dpdk.org/browse/dpdk/commit/lib/librte_ether/rte_ethdev.h?id=c3d0564cf0f00c3c9a61cf72bd4bd1c441740637 > > is bad: > struct eth_dev_ops > is churned, no comment, and a #ifdef that changes the structure > according to compilation! This is a very good example as it outlines the difference between control structures and the fast path. We have this same exact trade off in the kernel a lot where we have highly optimized internal APIs towards modules and drivers but want to provide binary compatibility to a certain extend. As for the specific example you mention, it is relatively trivial to make eth_dev_ops backwards compatible by appending appropriate padding to the struct before a new major release and ensure that new members are added by replacing the padding accordingly. Obviously no ifdefs would be allowed anymore. > Should an application use the librte libraries of the DPDK: > - you can use RTE_VERSION and RTE_VERSION_NUM : > http://dpdk.org/doc/api/rte__version_8h.html#a8775053b0f721b9fa0457494cfbb7ed9 Right. This would be more or less identical to requiring a specific DPDK version in OVS_CHEC_DPDK. It's not ideal to require application to clutter their code with #ifdefs all over for every new minor release though. > - you can write your own wrapper (with CPU overhead) in order to have > a stable ABI, that wrapper should be tight to the versions of the librte > => the overhead is part of your application instead of the DPDK, > - *otherwise recompile your software, it is opensource, what's the > issue?* > > We are opened to any suggestion to have stable ABI, but it should never > remove the options to have fast/efficient/compilation/CPU execution > processing. Absolutely agreed. We also don't want to add tons of abstraction and overcomplicate everything. Still, I strongly believe that the definition of stable interfaces towards applications and especially PMD is essential. I'm not proposing to standardize all the APIs towards applications on the level of POSIX. DPDK is in early stages and disruptive changes will come along. What I would propose on an abstract level is: 1. Extend but not break API between minor releases. Postpone API breakages to the next major release. High cadence of major releases initially, lower cadence as DPDK matures. 2. Define ABI stability towards PMD for minor releases to allow isolated packaging of PMD by padding control structures and keeping functions ABI stable. I realize that this might be less trivial than it seems without sacrificing performance but I consider it effort well spent. Thomas