From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <vincent.jardin@6wind.com> Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id ECA755320 for <dev@dpdk.org>; Wed, 29 Jan 2014 17:33:30 +0100 (CET) Received: by mail-wg0-f46.google.com with SMTP id x12so3960497wgg.25 for <dev@dpdk.org>; Wed, 29 Jan 2014 08:34:49 -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=IwFKDINZ5fBFI0cWlh7TQMWCGDLcI1ZQoZ7X65Tzu6I=; b=DJUB8stTHfarx+2mKyCPgKsqFzsHXb0YppnEKezmOwe/PGdu6ST1+AHt8cQ1zlN9QL J2GmCGZhD780y6bYHAzStWLaHw/IUAG8LWHf2sNO1gB3kcSiUUyZfOerbbeW0s8Teih9 cC1QPUnXs2Rk4OdXbTrUwS9Ebj1rPSxPHU/w6Ffnw1azYC1LdBbEGvbiY135tzXPq42n WzUjaq7hlA1ZE4eDYs63alLLmnk1x1TdEC2mGRcYu5QzQ9PUGW0sisZsFhF1HRij1nu+ 2hZDDiY0m1ZhXdso65+PEDfOAhmFLmjVKKd19zrW0gmrQ6m1OPq1i9Egc+Qns21/U5xU Al1g== X-Gm-Message-State: ALoCoQkGAsc4yq/zCxWUb5w+iHdN7XbTbRcniJ03n7cOWMAB7YYhAz8oYLKvY/jfUFpgxYHehw4U X-Received: by 10.180.98.165 with SMTP id ej5mr1021315wib.33.1391013289329; Wed, 29 Jan 2014 08:34:49 -0800 (PST) Received: from saturne.dev.6wind.com (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id q2sm5965162wjq.0.2014.01.29.08.34.47 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 29 Jan 2014 08:34:48 -0800 (PST) Message-ID: <52E92DA6.9070704@6wind.com> Date: Wed, 29 Jan 2014 17:34:46 +0100 From: Vincent JARDIN <vincent.jardin@6wind.com> 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 <tgraf@redhat.com> References: <1390873715-26714-1-git-send-email-pshelar@nicira.com> <52E7D13B.9020404@redhat.com> <CALnjE+rP29s8mkiKPtppt-a8jMn-B2qS7+re2ZBd8bK46ozUPA@mail.gmail.com> <52E8B88A.1070104@redhat.com> <52E8D772.9070302@6wind.com> <52E8E2AB.1080600@redhat.com> In-Reply-To: <52E8E2AB.1080600@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@openvswitch.org" <dev@openvswitch.org>, dev@dpdk.org, Gerald Rogers <gerald.rogers@intel.com>, 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 <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> X-List-Received-Date: Wed, 29 Jan 2014 16:33:31 -0000 Thomas, First and easy answer: it is open source, so anyone can recompile. So, what's the 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 long as we agree on this limited scope, we'll think about it and provide a proposal on dev@dpdk.org mailing list. > 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. Of course, it is basic C! >> 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 get lost: do you mean ABI + API toward the PMDs or towards the applications using the librte ? Best regards, Vincent