From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 59BE2558D for ; Mon, 13 Jun 2016 17:09:53 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 13 Jun 2016 08:09:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,466,1459839600"; d="scan'208";a="827079420" Received: from lculbert-sp4.amr.corp.intel.com ([10.252.8.8]) by orsmga003.jf.intel.com with SMTP; 13 Jun 2016 08:09:26 -0700 Received: by (sSMTP sendmail emulation); Mon, 13 Jun 2016 16:09:24 +0025 Date: Mon, 13 Jun 2016 16:09:24 +0100 From: Bruce Richardson To: Jerin Jacob Cc: dev@dpdk.org, thomas.monjalon@6wind.com, ferruh.yigit@intel.com, Maciej Czekaj , Kamil Rytarowski , Zyta Szpak , Slawomir Rosek , Radoslaw Biernacki Message-ID: <20160613150923.GI15736@bricha3-MOBL3> References: <1465317632-11471-2-git-send-email-jerin.jacob@caviumnetworks.com> <1465826143-22159-1-git-send-email-jerin.jacob@caviumnetworks.com> <1465826143-22159-2-git-send-email-jerin.jacob@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1465826143-22159-2-git-send-email-jerin.jacob@caviumnetworks.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v4 01/19] net/thunderx/base: add hardware API for ThunderX nicvf inbuilt NIC X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 15:09:53 -0000 On Mon, Jun 13, 2016 at 07:25:25PM +0530, Jerin Jacob wrote: > Adds hardware specific API for ThunderX nicvf inbuilt NIC device under > drivers/net/thunderx/nicvf/base directory. > Hi Jerin, we are trying to move away from huge drops of shared code in a single patchfile, so as to make the commits smaller and then easier to review. Can you split this patch into e.g. 3+ smaller commits based around logical functionality. For example, the base code mailbox functionality in the mbox.[ch] files could be its own commit. Obviously, the finer-grained the breakdown the better :-), but I'd rather not see patches >1 kloc looking to be merged in. Regards, /Bruce