From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id CBA361075 for ; Thu, 16 Mar 2017 18:30:00 +0100 (CET) Received: by mail-wm0-f44.google.com with SMTP id n11so117899444wma.1 for ; Thu, 16 Mar 2017 10:30:00 -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=XWIGlotZRd4eNvv1ONjqAgNxCl3gMjvTCeXa8CenaVo=; b=vXj65pjC4jhYg2i8zZGMpJCEuK+eDy6RPi1GpGgYHu0ZA/d+m5LKV/RHzqeJYTw3eE AjWcU3f9F3tfHVZpmFZG+HRLuwCjaJ+KuX0kd9LP3Drt62/1Cgv5zf4PFPBugZ6foild NxKhA2lRkR0YAX6Mnd+A6cwtdK5AqIfFl+xIlqdsU1+K7/da6N9r0rgGEUn8tPRKpGB+ iGF2zQPK76tesaTwoNGxdWXiX+19cp0+y3i5AcH5X7uajYetRL0k/RmkiVSD3LjSapHm uFAuTtIoSey7UzoVjd7qkmRrQugdI5/Y6ppimr/dHbZ3fMZai+a775HA7IB7RfGvk/bp lNlA== 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=XWIGlotZRd4eNvv1ONjqAgNxCl3gMjvTCeXa8CenaVo=; b=O8UJOESw0j+XxRO4pgqJc/QYci0YW/K3fgICpgKn+dtt5PmzQYNSBXlqvj5EJ5bN1O 3ONniHlqYZDiSQI6zAuQyebN0PJFKomrgbDilU7OhPf0e64ClUntCcoRR/Z3P/4y7YgM qjyHyb+9puZWX7IsZst8vVc61Kc1pum3TRoGnyfC5EQWa/0Tr40JQu6HCUg3Rzf1vexW fCWmiKwsJydHhmwB8XssK6RUs03Jd9GJt4pYQ2xf/lWKqYfWhvvOD6L1xxW2qXkya2VA fEVW6jZ7otjRyTfkhhgi+p9oogsCwbSRWtAjkbwxik2M5JWwkHVpBBBhmGV/VGdnrvMC Wwyg== X-Gm-Message-State: AFeK/H2uUnMHxRYZjjN4O9ON5tWVz/ZchnbND2fXaMI7PDVNL2dSlQZJi0En2FEYo75RtrmR X-Received: by 10.28.130.212 with SMTP id e203mr9758628wmd.104.1489685400545; Thu, 16 Mar 2017 10:30:00 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id m29sm6984337wrm.38.2017.03.16.10.29.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 10:29:59 -0700 (PDT) From: Thomas Monjalon To: "Dumitrescu, Cristian" Cc: "O'Driscoll, Tim" , dev@dpdk.org, jerin.jacob@caviumnetworks.com, balasubramanian.manoharan@cavium.com, hemant.agrawal@nxp.com, shreyansh.jain@nxp.com, keith.wiles@intel.com, bruce.richardson@intel.com Date: Thu, 16 Mar 2017 18:29:59 +0100 Message-ID: <4544430.1vcQTJXfeh@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912652761170@IRSMSX108.ger.corp.intel.com> References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com> <106399437.xFH6ZF6NRJ@xps13> <3EB4FA525960D640B5BDFFD6A3D8912652761170@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:30:01 -0000 2017-03-16 16:23, Dumitrescu, Cristian: > ... > > > > 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. > 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.