From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id BA57F1396 for <dev@dpdk.org>; Thu, 16 Mar 2017 19:10:55 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id t189so54848483wmt.1 for <dev@dpdk.org>; Thu, 16 Mar 2017 11:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=R30FNCPfjd+gk49t6OtM4CDIqD3ZDVwkLqDaUJyjnrc=; b=G2sdW0+b7I0a75zRjyAwYoA9V2YXGgMIvehAlWMnCtI3WQEJw9JYt5ncVSNgM89TmH /xApKYRZEPCsw2i9f+3Q3iOVrplKaTy7hkc7wJTZ63RWIRZ7VRRjjBMtzBuIpxqfT0O3 RRd1qzxzBN9Y9VBNL9YLQ8WzqpnzKdCUFfjqpUyMsgEzAZ1Z0J/IIuIsOQIl3No43R5L lbSvSxkVwh5nig6VxhX27Fkg3AEiqpEQW9mvLEzD9VvF1g9576Rrv1p+sv4yRH/4jqr1 wHstPE5wAGS/PoLogK3X5M5RHyV6VdCehUK8wnYU76UF/C+zwGbWu2ca5kCEZ5GXtRHM Z9Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=R30FNCPfjd+gk49t6OtM4CDIqD3ZDVwkLqDaUJyjnrc=; b=A6vs9kWOaeccPcN2bc6G18HBZo1oi35COr1Uyizb2DdHMCdhr4iuHo5mp2qnbTl6KB xmq4WOiHxVhp/sdfKras03BqggcWS/nljEdd/Z49LbUrzY6msHEFEWkvD86bcl8lH/zX BzGKMMmS1zrnXQOvxIP3kehqvWjGj/5XxxSXyGdCWbRJ3JW19R7bwFHMCiNwJGkS0YkF JepPK3now/SXUN3BlJ/fuQKEsUknaFN4opuLF9pZB89RhzH6knFCd9C7W/Dj5Nu4M7vl yVhNUXPs8ul/I+9e0bjy+uhNxS+YvC2W/+IWP2nbnuhSiRlHgMXoJnrmG0M6CsV5VnCn vcpw== X-Gm-Message-State: AFeK/H3c4/jTwgcJ+fwaYkT6bPaNdYK53ccCKVY1A6gMiYtSbn1MWgotkrrgpz4V5Gg/UcaF X-Received: by 10.28.18.73 with SMTP id 70mr3676168wms.41.1489687855147; Thu, 16 Mar 2017 11:10:55 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id 40sm7068198wry.22.2017.03.16.11.10.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 11:10:54 -0700 (PDT) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>, konstantin.ananyev@intel.com Cc: "O'Driscoll, Tim" <tim.odriscoll@intel.com>, dev@dpdk.org, jerin.jacob@caviumnetworks.com, balasubramanian.manoharan@cavium.com, "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>, "shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>, "Wiles, Keith" <keith.wiles@intel.com>, "Richardson, Bruce" <bruce.richardson@intel.com>, techboard@dpdk.org Date: Thu, 16 Mar 2017 19:10:53 +0100 Message-ID: <3089139.1r3dZqkNdq@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891265276121D@IRSMSX108.ger.corp.intel.com> References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com> <4544430.1vcQTJXfeh@xps13> <3EB4FA525960D640B5BDFFD6A3D891265276121D@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 2/2] ethdev: add hierarchical scheduler API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <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: Thu, 16 Mar 2017 18:10:55 -0000 2017-03-16 17:40, Dumitrescu, Cristian: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2017-03-16 16:23, Dumitrescu, Cristian: > > > ... <snip> > > > > > > > > Thomas, given Tim's confirmation of Intel's plans to implement this API > > for > > > > the ixgbe and i40e drivers in DPDK release 17.8, are you in favour of > > including > > > > this API in 17.5 with experimental tag (subject to full API agreement being > > > > reached)? > > > > > > > > I think starting a branch in a dedicated "next" repo is a better approach. > > > > rte_flow and eventdev were (and will be) integrated only when at least > > one > > > > hardware device is supported. > > > > I suggest to follow the same workflow. > > > > > > > > > > Thomas, if this is the only path forward you are willing to support, then let's > > go this way, but let's make sure we are all on the same page with the terms > > and conditions that apply. > > > > > > Do you agree now to merge this next-tree to DPDK once this API is > > implemented for at least one PMD? We would like to avoid getting any last > > minute objections from you or anybody else on the fundamentals; if you > > have any, please let's discuss them now. > > > > At least one "hardware" PMD, yes. It would prove the API can work for real. > > About accepting it definitely in a given release, it will be checked > > with the technical board on Monday. > > > > OK, great, thank you. Is the agenda of the technical board meetings published in advance somewhere? For the previous meeting, it was published: https://bimestriel.framapad.org/p/r.a5199d22813a5ac79d1d365b9cecb905 For the next one, please Konstantin, could you publish the agenda on a pad? > > > How do we manage the API freeze on the next-tree? Once the API is > > agreed, we would like to freeze it so the driver development can proceed; > > we can then do some reasonably small changes to the API based on the > > learnings we get during driver development. We would like to welcome any > > parties interested in contributing to join Cavium, Intel and NXP in this effort, > > but we would like to avoid any last minute major API change requests. > > > > You are taking it the wrong way. Your main concern is to not be disturbed > > with change requests. It should be the contrary: you have a chance to > > work with other vendors to test and improve the API. > > You should embrace this chance and delay the API freeze as much as > > possible. > > Not really. We definitely welcome change requests done in a timely manner. My concern is about last minute change requests, such as major API change requests just a few days before the release when driver development is complete. Is there a policy in place to prevent against such events for next-tree type of development? No there is no such policy on a next- tree. It is free to the maintainer of the tree I guess.