From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 69AE01B667 for ; Tue, 6 Feb 2018 11:11:10 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 02:11:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,468,1511856000"; d="scan'208";a="25209760" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.91]) ([10.237.220.91]) by FMSMGA003.fm.intel.com with ESMTP; 06 Feb 2018 02:11:07 -0800 To: Rahul Lakkireddy Cc: "dev@dpdk.org" , Kumar A S , Surendra Mobiya , Nirranjan Kirubaharan , Indranil Choudhury , Thomas Monjalon References: <713e92d0143827f8af409763815cde15b9d40305.1517685185.git.rahul.lakkireddy@chelsio.com> <4e2eda5f-4697-906e-0596-84502add0af6@intel.com> <20180206092234.GB19019@chelsio.com> From: Ferruh Yigit Message-ID: <2ac87b2c-c7c7-b7c5-2353-7b0757fbd879@intel.com> Date: Tue, 6 Feb 2018 10:11:06 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180206092234.GB19019@chelsio.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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:11:11 -0000 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: >> On 2/4/2018 6:06 AM, Rahul Lakkireddy wrote: >>> From: Kumar Sanghvi >>> >>> Add firmware API for updating RSS hash configuration and key. Move >>> RSS hash configuration from cxgb4_write_rss() to a separate function >>> cxgbe_write_rss_conf(). >>> >>> Also, rename cxgb4_write_rss() to cxgbe_write_rss() for consistency. >>> >>> Original work by Surendra Mobiya >>> >>> Signed-off-by: Kumar Sanghvi >>> Signed-off-by: Rahul Lakkireddy >>> --- >>> doc/guides/nics/cxgbe.rst | 2 + >>> doc/guides/nics/features/cxgbe.ini | 1 + >>> doc/guides/rel_notes/release_18_02.rst | 3 ++ >>> drivers/net/cxgbe/base/adapter.h | 4 +- >>> drivers/net/cxgbe/base/common.h | 3 ++ >>> drivers/net/cxgbe/base/t4_hw.c | 73 +++++++++++++++++++++++++++ >>> drivers/net/cxgbe/base/t4_regs.h | 25 +++++++++ >>> drivers/net/cxgbe/base/t4fw_interface.h | 89 +++++++++++++++++++++++++++++++++ >>> drivers/net/cxgbe/cxgbe.h | 2 + >>> drivers/net/cxgbe/cxgbe_ethdev.c | 32 ++++++++++++ >>> drivers/net/cxgbe/cxgbe_main.c | 79 ++++++++++++++++++++++------- >>> 11 files changed, 295 insertions(+), 18 deletions(-) >> >> 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. > > Thanks, > Rahul >