From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <stephen@networkplumber.org> Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by dpdk.org (Postfix) with ESMTP id B9BFC4CE4 for <dev@dpdk.org>; Mon, 12 Nov 2018 17:44:01 +0100 (CET) Received: by mail-pg1-f176.google.com with SMTP id w7so4297011pgp.13 for <dev@dpdk.org>; Mon, 12 Nov 2018 08:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=G3PqPejj1mD9EdlIuJWx/en+w0zibRefLOzVQvXEU+Q=; b=T9Vv9Um9hm1Zl3EFqtIjgDVX75k68AmDvlbeapI67oA10p3qAXNze5SEcadSKDJbSM X/8QNlLK+zFmHvggZPGGExLHNFN1SUHbqQeURApg8u8+cRMnymdwY3g0dPuuvdACz+Jm 5e5nrF136MgoFl+OAyUzoszf0UBziJpgkmmBn9T6zRmUNO5byCK+xlQzEBQgdfe3u90N B+YYSHI0YX0Jw8trlWfF1qBbjVebHCZdO4BMlHMcPONBtyoD2z5zLfOrEoXajVr3LY+y /oW3wTQX0LUWKb912oBGTQ9e6QWM0FOfkXJLDjA5yvSnyB73fn1b0QD4QPSR/XuPAM8Y V8uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=G3PqPejj1mD9EdlIuJWx/en+w0zibRefLOzVQvXEU+Q=; b=ZvsrGAqx382ZJD8thzOCeGN6s3c9oVGMzwouia0x3WyEk7CkAUYU8trzdagd9GV2zX p0+zq3CSXKdIFB/c4cz/HiuM8ccYvuKYMXlKkLPYEfkeUGMAK5n3qNpYSZL2O+uCiRrI xHMIv5OpfadYslgOs2jkViWphiKuuCQV4ACdRqJvMLLMDkMElruu8kRGTTQR4JF2Rbgw 6jfnnryfwh+f1aAkAUoYz/JE+VAv5mQ1UB1wvBcyHBsHLU33qGNTjM+3+Cg80nNYbZzb jnPP+AZge4tUPHSIb7BcKdRlNY6Wa+keUcGdclEUGvezrQI+pwq1BP86l9O42kfpocZf X0Xg== X-Gm-Message-State: AGRZ1gLqpMxcb1jMoPTAAghGVsc3gKf7P6Y5gg2RtbkkUfICxfOCBdVf AZomMjZ67BwOV3YSrYFuzEoX0Q== X-Google-Smtp-Source: AJdET5dOVYV0b2Bf4i79GPKVHCziash3OCgVyfTsu3BpsICYYiqx7zej4Uemi7fel524P1PkN6/AJQ== X-Received: by 2002:a63:9712:: with SMTP id n18mr1404512pge.295.1542041040697; Mon, 12 Nov 2018 08:44:00 -0800 (PST) Received: from xeon-e3 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id h70-v6sm21803337pfe.65.2018.11.12.08.44.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 12 Nov 2018 08:44:00 -0800 (PST) Date: Mon, 12 Nov 2018 08:43:53 -0800 From: Stephen Hemminger <stephen@networkplumber.org> To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com> Cc: "Richardson, Bruce" <bruce.richardson@intel.com>, "Burakov, Anatoly" <anatoly.burakov@intel.com>, Jerin Jacob <jerin.jacob@caviumnetworks.com>, "dev@dpdk.org" <dev@dpdk.org>, "techboard@dpdk.org" <techboard@dpdk.org> Message-ID: <20181112084353.506b2786@xeon-e3> In-Reply-To: <2601191342CEEE43887BDE71AB977258010CE49651@IRSMSX106.ger.corp.intel.com> References: <20181110091727.GA20155@jerin> <fd3172fa-6016-8722-6874-6b6d711976c2@intel.com> <2601191342CEEE43887BDE71AB977258010CE495F1@IRSMSX106.ger.corp.intel.com> <59AF69C657FD0841A61C55336867B5B0726DC700@IRSMSX103.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258010CE49651@IRSMSX106.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [dpdk-techboard] DPDK techboard minutes of October 24 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 12 Nov 2018 16:44:02 -0000 On Mon, 12 Nov 2018 12:36:45 +0000 "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote: > > -----Original Message----- > > From: Richardson, Bruce > > Sent: Monday, November 12, 2018 12:22 PM > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Burakov, Anatoly <anatoly.burakov@intel.com>; Jerin Jacob > > <jerin.jacob@caviumnetworks.com>; dev@dpdk.org > > Cc: techboard@dpdk.org > > Subject: RE: [dpdk-techboard] [dpdk-dev] DPDK techboard minutes of October 24 > > > > > > > > > -----Original Message----- > > > From: techboard [mailto:techboard-bounces@dpdk.org] On Behalf Of Ananyev, > > > Konstantin > > > Sent: Monday, November 12, 2018 11:24 AM > > > To: Burakov, Anatoly <anatoly.burakov@intel.com>; Jerin Jacob > > > <jerin.jacob@caviumnetworks.com>; dev@dpdk.org > > > Cc: techboard@dpdk.org > > > Subject: Re: [dpdk-techboard] [dpdk-dev] DPDK techboard minutes of October > > > 24 > > > > > > > > > Hi Anatoly, > > > > > > > > Meeting notes for the DPDK technical board meeting held on > > > > > 2018-10-24 > > > > > > > > > > Attendees: > > > > > - Bruce Richardson > > > > > - Ferruh Yigit > > > > > - Hemant Agrawal > > > > > - Jerin Jacob > > > > > - Konstantin Ananyev > > > > > - Maxime Coquelin > > > > > - Olivier Matz > > > > > - Stephen Hemminger > > > > > - Thomas Monjalon > > > > > > > > > > 0) DPDK acceptance policy on un-implemented API > > > > > - New APIs without implementation is not accepted. > > > > > - In order to accept a new API, At minimum > > > > > a) Need to provide an unit test case or example application > > > > > b) If the API is about HW abstraction, at least one driver should be > > > > > implemented. Preferably two. > > > > > c) If there are strong objections on ML about the need for more than > > > > > one driver for a specific API then the technical board can make a > > > > > decision. > > > > > - Konstantin volunteered to send existing un-implemented API to the > > > > > mailing list. > > > > > - The existing un-implemented APIs will be deprecated in v19.05. > > > > > - Deprecated un-implemented API will be removed in v19.08 > > > > > > > > > > > > > Does this also apply to unimplemented parts of the existing API? For > > > > example, malloc API has long had a "name" parameter which goes > > > > unimplemented through entire lifetime of DPDK project. It would be > > > > good to drop this thing entirely as it's clear it's not going to be > > > > implemented any time soon :) > > > > > > > > > > Sounds like a good idea to me. > > > Konstantin > > > > While a good idea in theory, I'm not sure the cost-benefit pays off for this one. Given the fact that the extra parameter is rather harmless, > > the benefit seems minimal compared to the effort which would be involved for everyone to have to change every rte_malloc call in every > > app! > > I am agree about massive amount of changes, though I thought Anatoly sort of volunteering for it :) > About benefit - it would save us spilling/restoring one register for each rte_malloc() call. > Probably not that important, as rte_malloc() usually is used from data-path, but still. > Plus it doesn't look good to have a function with parameter that would never be used. > Konstantin > > I agree, we should do these kind of cleanups, but only on ABI breaking releases. Too late now for 18.11 and next one is probably 19.11