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: Mon, 28 Nov 2016 11:54:25 +0100
Message-ID: <15420823.7ghYzVRe3h@xps13>
References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com>
 <1479922585-8640-1-git-send-email-tomaszx.kulasek@intel.com>
 <1479922585-8640-2-git-send-email-tomaszx.kulasek@intel.com>
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-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49])
 by dpdk.org (Postfix) with ESMTP id 061ACB6D
 for <dev@dpdk.org>; Mon, 28 Nov 2016 11:54:26 +0100 (CET)
Received: by mail-wm0-f49.google.com with SMTP id f82so150821747wmf.1
 for <dev@dpdk.org>; Mon, 28 Nov 2016 02:54:26 -0800 (PST)
In-Reply-To: <1479922585-8640-2-git-send-email-tomaszx.kulasek@intel.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>

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.