From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id D07285323 for ; Wed, 29 Jan 2014 11:25:41 +0100 (CET) Received: by mail-wg0-f43.google.com with SMTP id y10so3002898wgg.34 for ; Wed, 29 Jan 2014 02:27:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=anoYGsmZCGbtx6pptjoY3iF9tztaKsygn/74iZrzM/w=; b=I/EsYPCDjQvgDJjoxvzI7KG5kQHHrVZv63NeZNoRNI1ceFuZTDordzjXYvolJccjdA 93toQAP4+XMkLpK0SqHxAW5amLGsFZdufag7ii8diiBGZHImMUncsGfiIJe5P/HNvfv/ gK3xxrLeYXdSvTLkwrdLf7m1VuGMInApH3OAeeUSWqNUhfeBlUlVjVIDNefx2k+CkwE2 npqB80irMgpBOVUYQfzBMxriWYkUt3h1Cn0ZoVKd4a7/hYnIE3XyDcDsC2ApWByOcUW3 RzVTHzLHdFo+Bl/8ubDeL8/PL1TPrCKeOGAgmv2hjimAv5jwX9LuJ6D+RVObET5PvdlQ 6eGw== X-Gm-Message-State: ALoCoQnGfH5PPu34bJsG/TYKP4EKGgam/FFXjI1syRSonp8m8ROohngKg8Nm/sxt0tQ5K4exbn9R X-Received: by 10.180.73.173 with SMTP id m13mr7361840wiv.52.1390991220211; Wed, 29 Jan 2014 02:27:00 -0800 (PST) Received: from saturne.dev.6wind.com (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id n15sm4364956wij.3.2014.01.29.02.26.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 29 Jan 2014 02:26:59 -0800 (PST) Message-ID: <52E8D772.9070302@6wind.com> Date: Wed, 29 Jan 2014 11:26:58 +0100 From: Vincent JARDIN Organization: www.6wind.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Thomas Graf References: <1390873715-26714-1-git-send-email-pshelar@nicira.com> <52E7D13B.9020404@redhat.com> <52E8B88A.1070104@redhat.com> In-Reply-To: <52E8B88A.1070104@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 10:25:42 -0000 Hi Thomas, On 29/01/2014 09:15, Thomas Graf wrote: > The obvious and usual best practise would be for DPDK to guarantee > ABI stability between minor releases. > > Since dpdk-dev is copied as well, any comments? 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 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! 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 - 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. Best regards, Vincent