From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DFD41A04B1; Mon, 23 Nov 2020 11:00:16 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7BDDB375B; Mon, 23 Nov 2020 11:00:15 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id D2A6AA3; Mon, 23 Nov 2020 11:00:12 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 87A9E5C010F; Mon, 23 Nov 2020 05:00:11 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 23 Nov 2020 05:00:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= w9rIgo+FpZPkwbqFSx6Pz2a7c9eRDbwHSxnAcHeyFeI=; b=NvTb2CavwX4xSodP kj+3Wqlz7d/lglEn81pTyNb3MTHsR3OqGdBU4Y/AFfB2WRpNlV30ycZq3ppvMtIj A6v2fiUwT4j2rciBpWQviJsmmapF1WHojQGIfXt01lbEfjf+zKG1d5Ag0LH0Ff6/ rKNkbTjeupqolGxbCGzKMJiIWFpmoj7k8wmvtqb2AB/lh6ThoOlpw9rj1/Zi1eE2 iDzlpXad3cbkPhy9G/EAD3W4g3D5IyYqK1zXYrYSkiOAyk7FxbA1R7kyQLa+tVmd 4JlE5OrGUFGfSuhBHDpRNPytpm2J9dmceyrEE7PR99DFj8pcuRJ7VwWmXcKEDJS8 DgxYbg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=w9rIgo+FpZPkwbqFSx6Pz2a7c9eRDbwHSxnAcHeyF eI=; b=h3m8y6uJceq5i4YJuLN76vHLvhMc4EmQrBgelfUpwOqkfIOFqO0EDAiBD hsrsniHgSFhbx0L63QlYe95EVNjqm/JGeDNF/ImFSKV4m/4OWg8dlVb91Ot1pAVb QOjXeIdVZvK3awI/xPVH5nhwNejK1Vw3g36yD/83xnNUks5RWnJiQ1umcBGRYIDT Ok5038DYmXDF5CMOQGxdUa+vn2roGE2ZQjb8XigxSLaJ8WUpI2hBhMyg8S8pjPX8 /zqZyFkgUoHvvriWI/b+4lCjCCDvHcfpctCwF/GuPu7GnwqVRfjENh3JgQ0QlhwE 7Bw6gBKFoyjU+1leV3KvQiOlEmP1A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegiedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 54843328005E; Mon, 23 Nov 2020 05:00:10 -0500 (EST) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: Bruce Richardson , dev@dpdk.org, techboard@dpdk.org Date: Mon, 23 Nov 2020 11:00:08 +0100 Message-ID: <2616226.gbbvxhKr92@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61442@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35C61442@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [dpdk-techboard] Minutes of Technical Board Meeting, 2020-11-18 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 23/11/2020 10:30, Morten Br=C3=B8rup: > Bruce, >=20 > Here's my input as a developer of hardware appliances. It is my opinion, = and as such may contradict the trend towards making DPDK a library, rather = than a development kit. >=20 > > DPDK build configuration - future enhancements > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > There are multiple requests (sometimes controversial) for new abilities > > to add into DPDK build system. > > In particular, request from few different teams: > > - add ability to enable/disable individual apps/libs > > - override some build settings for specific libs/drivers >=20 > My wish list, in prioritized order: >=20 > 1. The ability to remove features to reduce complexity - and thus the lik= elihood of bugs! >=20 > Remember to consider this in application context. >=20 > Background: Our previous firmware used the Linux kernel, and some loadabl= e modules. We ran into a lot of extremely rare and unexpected cases where t= he Linux kernel network stack did something completely unusual, and our fir= mware needed to consider all these exceptional cases. This is one of the ke= y reasons we switched to DPDK - the fast path libraries are clean and simpl= e, and don't do anything we didn't ask them to do. >=20 > DPDK example: If support for segmented packets are considered "required" = by DPDK libraries and drivers, is it also required for applications to supp= ort segmented packet? If the application doesn=E2=80=99t need segmented pac= kets, can it safely assume that no DPDK libraries or drivers create segment= ed packets under any circumstances? If support for segmented packets is a c= ompile time option, there is an implicit guarantee that they don't appear. The primary rule in DPDK is that the application remains in control. If the application does not call the API function for a feature, it won't be enabled. So no need to remove the unused libraries. > 2. The ability to remove/tweak features to improve *application* performa= nce in specific environments would be good. >=20 > E.g. removing support for multiple mbuf pools would free up an mbuf field= (m->pool) for application use. > So would removing support for segmented packets (m->nb_segs, m->next). >=20 > Both of these modifications would also reduce complexity, although they w= ould increase source code complexity in all the libraries and drivers needi= ng to support a multidimensional matrix of features. (I highly doubt that a= ll libraries support the combination of all features today... I remember ha= ving to argue strongly for the DPDK eBPF library to support reading data in= side segmented packets.) Because code must remain simple, the mbuf layout is fixed (except dynamic fields). > 3. Removing cruft that has no effect on performance or similar, is "nice = to have". >=20 > E.g. drivers for hardware that we do not use. >=20 > > As a first step to move forward - produce design doc of current build > > system. > > Discuss further enhancements based on that doc. >=20 > > While planning changes to the build system backward compatibility > > with 20.11 should be considered. >=20 > Backward compatibility is not a high priority for us. It is an extremely = rare event for us to upgrade to a new version of any external software (Lin= ux Kernel, DPDK and other libraries) or build tools, because we consider sw= itching any of it to another version high effort (e.g. it requires extensiv= e testing). In this perspective, having to change some details in the build= system is a relatively small effort. >=20 > With this said, the documentation of each DPDK release should include a c= hapter describing what an application developer should do different than wi= th the previous release. E.g. the Release Note enumerates the key modificat= ions as bullet points, but it is not always obvious how that affects an app= lication being developed. (DPDK generally has great documentation, but is s= omewhat lacking in this area.) >=20 > I know that ABI Stability is supposed to make much of this go away, but D= PDK is clearly not there yet. >=20 > > AR to Bruce to create initial version of the DD. > >=20 >=20 > The following may be scope creep, so just consider it me thinking out lou= d: >=20 > Consider a general design documents in the form of a "life of an mbuf" do= cument, describing how mbufs are pre-allocated for driver RX descriptors, a= nd then handed over to the application trough the receive function, and the= n possibly going through defragmentation and reordering libraries, and then= handed over to another driver's transmit function, which uses the mbufs to= set up TX descriptors, and after transmission frees the mbufs to their ori= ginal pool, where they are ultimately allocated again by a driver to refill= its RX descriptor pool. >=20 > The document can start off with the simple case with a single non-segment= ed, non-fragmented, in-order packet. And then it can be extended with varia= tions, e.g. adding the description of segmented packets would explain how t= he m->nb_segs and m->next are being used when the packet is handled by the = drivers and libraries. >=20 > In the context of being able to enable/disable libraries and features, th= e purpose of this document would be to help showing interdependencies. I agree we need this kind of doc. It could be part of the prog guide. =46eel free to draft a skeleton.