From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH v12 1/6] ethdev: add Tx preparation
Date: Thu, 22 Dec 2016 19:07:34 +0530
Message-ID: <20161222133732.GA12907@localhost.localdomain>
References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com>
 <3042915272161B4EB253DA4D77EB373A14F57CDE@IRSMSX102.ger.corp.intel.com>
 <2601191342CEEE43887BDE71AB9772583F0E2A74@irsmsx105.ger.corp.intel.com>
 <7594197.BWrLiCir60@xps13>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "Kulasek, TomaszX"
 <tomaszx.kulasek@intel.com>, <dev@dpdk.org>, "olivier.matz@6wind.com"
 <olivier.matz@6wind.com>, "Richardson, Bruce" <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on0075.outbound.protection.outlook.com [104.47.36.75])
 by dpdk.org (Postfix) with ESMTP id 18A4C10D1C
 for <dev@dpdk.org>; Thu, 22 Dec 2016 14:37:58 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <7594197.BWrLiCir60@xps13>
List-Id: DPDK patches and discussions <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 Thu, Dec 22, 2016 at 02:14:45PM +0100, Thomas Monjalon wrote:
> 2016-12-02 00:10, Ananyev, Konstantin:
> > I have absolutely no problem to remove the RTE_ETHDEV_TX_PREPARE and associated logic.
> > I personally don't use ARM boxes and don't plan to,
> > and in theory users can still do conditional compilation at the upper layer, if they want to. 
> 
> Yes you're right. The application can avoid calling tx_prepare at all.

There are applications inside dpdk repo which will be using tx_prep so
in that case, IMHO, let the ifdef inside the DPDK library and disable it by
default so that if required we can disable it in one shot on integrated
controllers targets where is the system has only one integrated controller and
integrated controller does not need tx_prep


> No need of an ifdef inside DPDK.