From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH v12 1/6] ethdev: add Tx preparation
Date: Thu, 01 Dec 2016 17:24:11 +0100
Message-ID: <1734448.0id6dCbsBT@xps13>
References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com>
 <1479922585-8640-2-git-send-email-tomaszx.kulasek@intel.com>
 <15420823.7ghYzVRe3h@xps13>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, konstantin.ananyev@intel.com, olivier.matz@6wind.com,
 bruce.richardson@intel.com
To: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wj0-f180.google.com (mail-wj0-f180.google.com
 [209.85.210.180]) by dpdk.org (Postfix) with ESMTP id 5099958C5
 for <dev@dpdk.org>; Thu,  1 Dec 2016 17:24:14 +0100 (CET)
Received: by mail-wj0-f180.google.com with SMTP id qp4so209322362wjc.3
 for <dev@dpdk.org>; Thu, 01 Dec 2016 08:24:14 -0800 (PST)
In-Reply-To: <15420823.7ghYzVRe3h@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>

Please, a reply to this question would be greatly appreciated.

2016-11-28 11:54, Thomas Monjalon:
> Hi,
> 
> 2016-11-23 18:36, Tomasz Kulasek:
> > --- a/config/common_base
> > +++ b/config/common_base
> > @@ -120,6 +120,7 @@ CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
> >  CONFIG_RTE_LIBRTE_IEEE1588=n
> >  CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
> >  CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
> > +CONFIG_RTE_ETHDEV_TX_PREPARE=y
> 
> Please, remind me why is there a configuration here.
> It should be the responsibility of the application to call tx_prepare
> or not. If the application choose to use this new API but it is
> disabled, then the packets won't be prepared and there is no error code:
> 
> > +#else
> > +
> > +static inline uint16_t
> > +rte_eth_tx_prepare(__rte_unused uint8_t port_id, __rte_unused uint16_t queue_id,
> > +               __rte_unused struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
> > +{
> > +       return nb_pkts;
> > +}
> > +
> > +#endif
> 
> So the application is not aware of the issue and it will not use
> any fallback.