From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [PATCH v4 01/19] net/thunderx/base: add hardware API
 for ThunderX nicvf inbuilt NIC
Date: Mon, 13 Jun 2016 16:09:24 +0100
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
Cc: dev@dpdk.org, thomas.monjalon@6wind.com, ferruh.yigit@intel.com,
 Maciej Czekaj <maciej.czekaj@caviumnetworks.com>,
 Kamil Rytarowski <Kamil.Rytarowski@caviumnetworks.com>,
 Zyta Szpak <zyta.szpak@semihalf.com>,
 Slawomir Rosek <slawomir.rosek@semihalf.com>,
 Radoslaw Biernacki <rad@semihalf.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id 59BE2558D
 for <dev@dpdk.org>; Mon, 13 Jun 2016 17:09:53 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <1465826143-22159-2-git-send-email-jerin.jacob@caviumnetworks.com>
List-Id: patches and discussions about DPDK <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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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