From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 1188E1B61C for ; Tue, 6 Feb 2018 11:38:40 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B85BD20BF2; Tue, 6 Feb 2018 05:38:39 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 06 Feb 2018 05:38:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=ptlSm67vDUSbC+Sy0lZsp/KnC1 vcVF39Z7+knRpd/2s=; b=GQKhd1oibT+ciJTmEFQLMBzupeNWhP3sGGN1Qb6LPH ekplwnd2jd7Gh8KojzvTp0PR+InmUe/3AoTaUBTJuVWfLMY/YeBbmkRLFL4WtQRU SCvX4w98duw+ah0Uj3Q44WrZPfpmDgw7SgiJO7RNlpboTxVzw2toSDz98uRtnx4q Y= 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-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ptlSm6 7vDUSbC+Sy0lZsp/KnC1vcVF39Z7+knRpd/2s=; b=QZdib9tQDyCqMhRtTIdzdS IlwgD0Eqa6xwF6UCEWOzkiDF4o4iLanuakEYtPi1IM9AsVlI1LpzldjS4STrTw5N 4faB0r75HGORB4cJBF+CVV/YX5z/Bdsl6nrwfNrdjwAFXtTsYhvL1vr2Lf3E12p8 X9RXdvvwzucMLa6KeM+BARjwjjILWYKDyOgaGkXSkHYfT1eKeN5tp/keaNyHutS/ GlIeImB6+R7lwdlYyfi5wAMjbNEzKfnaPWAGfcc2L4IxrEsz59UPhC+EomjLmk7Q AzOipcdjIumD5jyR6+l5z3EU472KuNSRgaKsY91qGLl1Keklgy8sw3QCnCyjiPqA == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 6BF7624108; Tue, 6 Feb 2018 05:38:39 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit , Rahul Lakkireddy Cc: "dev@dpdk.org" , Kumar A S , Surendra Mobiya , Nirranjan Kirubaharan , Indranil Choudhury Date: Tue, 06 Feb 2018 11:38:35 +0100 Message-ID: <12269159.jrIR7R1Xa1@xps> In-Reply-To: <2ac87b2c-c7c7-b7c5-2353-7b0757fbd879@intel.com> References: <20180206092234.GB19019@chelsio.com> <2ac87b2c-c7c7-b7c5-2353-7b0757fbd879@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 3/7] cxgbe: add support to update RSS hash configuration and key 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: Tue, 06 Feb 2018 10:38:40 -0000 06/02/2018 11:11, Ferruh Yigit: > On 2/6/2018 9:22 AM, Rahul Lakkireddy wrote: > > On Monday, February 02/05/18, 2018 at 22:39:55 +0530, Ferruh Yigit wrote: > >> I tend to get driver patches even after integration deadline, mainly because of > >> their limited scope. > >> But since these are new features, submitted just before rc3, adding with > >> questions in first patch, I am for postponing this patchset to next release and > >> do more review, what do you think? > > > > Does dpdk-next-net tree work similar to linux "next" trees? I mean does > > it represent the next release (DPDK 18.05-rc1) merge window? Can we > > explicitly mention in Patch title which tree it is targeted for viz. > > dpdk or dpdk-next-net? > > Hi Rahul, > > It is not like Linux next trees, this is more like Dave's net tree. > In dpdk responsibilities split into sub-trees, and all target current release, > patches merged into sub-trees and pulled by main tree in integration deadline. > > All network drivers and ethdev abstraction layer patches goes into next-net > sub-tree. > > > Briefly overall process is [1]: > - A new feature needs to be sent before proposal deadline, this can be a full > version of the set or RFC. Proposal deadline for the release announced in > https://dpdk.org/dev/roadmap > > - After that point code reviews done and new versions sent till integration > deadline. Accepted patches are integrated to release candidate 1 (rc1). > Of course patch can be reviewed and merged without waiting integration deadline. > If a patch not get an approval and merge into tree in integration deadline, > most probably it won't go into release. > > - Fixes can be sent from beginning of release to rcX. Only latest rcX mostly for > the fixes on features introduced in that release. > > - After rc1, code tested and fixes sent for found defects. No new feature > expected after rc1. > > - We go mostly to rc3 or rc4 before release. > > > [1] > Thomas, please correct me if I missed something. And this needs to be documented > indeed. If the patchset targets 18.05, it should be notified. I suggest --subject-prefix='PATCH 18.05'. Then it will be marked as Deferred in patchwork until the start of the 18.05 release cycle. We can review it but we do not apply it before the start of the cycle, because we don't see a real need for such "in advance" branch.