From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 7A961A3295
	for <public@inbox.dpdk.org>; Wed, 23 Oct 2019 12:18:21 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 521B81BFA7;
	Wed, 23 Oct 2019 12:18:20 +0200 (CEST)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by dpdk.org (Postfix) with ESMTP id 7AF8C1BF96
 for <dev@dpdk.org>; Wed, 23 Oct 2019 12:18:18 +0200 (CEST)
X-Amp-Result: UNKNOWN
X-Amp-Original-Verdict: FILE UNKNOWN
X-Amp-File-Uploaded: False
Received: from orsmga007.jf.intel.com ([10.7.209.58])
 by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 23 Oct 2019 03:18:17 -0700
X-IronPort-AV: E=Sophos;i="5.68,220,1569308400"; d="scan'208";a="188207337"
Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.95])
 by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
 23 Oct 2019 03:18:15 -0700
Date: Wed, 23 Oct 2019 11:18:12 +0100
From: Bruce Richardson <bruce.richardson@intel.com>
To: Ori Kam <orika@mellanox.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org>,
 Ferruh Yigit <ferruh.yigit@intel.com>,
 Andrew Rybchenko <arybchenko@solarflare.com>,
 "jingjing.wu@intel.com" <jingjing.wu@intel.com>,
 "stephen@networkplumber.org" <stephen@networkplumber.org>
Message-ID: <20191023101812.GB482@bricha3-MOBL.ger.corp.intel.com>
References: <1569479349-36962-1-git-send-email-orika@mellanox.com>
 <1571326337-42692-1-git-send-email-orika@mellanox.com>
 <1571326337-42692-3-git-send-email-orika@mellanox.com>
 <1578943.idabHBMeuZ@xps>
 <AM4PR05MB3425C0F47CC6F119B3AFA4EEDB6B0@AM4PR05MB3425.eurprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AM4PR05MB3425C0F47CC6F119B3AFA4EEDB6B0@AM4PR05MB3425.eurprd05.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Subject: Re: [dpdk-dev] [PATCH v4 02/15] ethdev: add support for hairpin
	queue
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Wed, Oct 23, 2019 at 10:09:45AM +0000, Ori Kam wrote:
> Hi Thomas,
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Wednesday, October 23, 2019 10:05 AM
> > To: Ori Kam <orika@mellanox.com>
> > Cc: dev@dpdk.org; Ferruh Yigit <ferruh.yigit@intel.com>; Andrew Rybchenko
> > <arybchenko@solarflare.com>; jingjing.wu@intel.com;
> > stephen@networkplumber.org
> > Subject: Re: [dpdk-dev] [PATCH v4 02/15] ethdev: add support for hairpin queue
> > 
> > 17/10/2019 17:32, Ori Kam:
> > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > >  /**
> > > + * @warning
> > > + * @b EXPERIMENTAL: this API may change, or be removed, without prior
> > notice
> > > + *
> > > + * A structure used to return the hairpin capabilities that are supported.
> > > + */
> > > +struct rte_eth_hairpin_cap {
> > > +	uint16_t max_n_queues;
> > > +	/**< The max number of hairpin queues (different bindings). */
> > > +	uint16_t max_rx_2_tx;
> > > +	/**< Max number of Rx queues to be connected to one Tx queue. */
> > > +	uint16_t max_tx_2_rx;
> > > +	/**< Max number of Tx queues to be connected to one Rx queue. */
> > > +	uint16_t max_nb_desc; /**< The max num of descriptors. */
> > > +};
> > 
> > I think you can switch to "comment-first style" for this struct.
> > 
> 
> O.K I will change.
> 
> > 
> > > +#define RTE_ETH_MAX_HAIRPIN_PEERS 32
> > 
> > Usually I think such define is in the build config.
> > Any other opinion?
> > 
+1 for not moving it to the build config unless absolutely necessary.