From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <tomaszx.kulasek@intel.com>
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
by dpdk.org (Postfix) with ESMTP id 8F7CE58DB
for <dev@dpdk.org>; Thu, 1 Dec 2016 23:31:45 +0100 (CET)
Received: from fmsmga006.fm.intel.com ([10.253.24.20])
by fmsmga103.fm.intel.com with ESMTP; 01 Dec 2016 14:31:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,284,1477983600"; d="scan'208";a="38046180"
Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25])
by fmsmga006.fm.intel.com with ESMTP; 01 Dec 2016 14:31:43 -0800
Received: from irsmsx102.ger.corp.intel.com ([169.254.2.79]) by
irsmsx110.ger.corp.intel.com ([163.33.3.25]) with mapi id 14.03.0248.002;
Thu, 1 Dec 2016 22:31:42 +0000
From: "Kulasek, TomaszX" <tomaszx.kulasek@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, "Ananyev, Konstantin"
<konstantin.ananyev@intel.com>, "olivier.matz@6wind.com"
<olivier.matz@6wind.com>, "Richardson, Bruce" <bruce.richardson@intel.com>
Thread-Topic: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation
Thread-Index: AQHSRbBkXBK52xh5bEGv2Yak9bo9p6DuQDCAgAUTIYCAACxPUIAADdsAgAAl19A=
Date: Thu, 1 Dec 2016 22:31:42 +0000
Message-ID: <3042915272161B4EB253DA4D77EB373A14F57CDE@IRSMSX102.ger.corp.intel.com>
References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com>
<1734448.0id6dCbsBT@xps13>
<3042915272161B4EB253DA4D77EB373A14F57CAE@IRSMSX102.ger.corp.intel.com>
<2505996.o0gdCe9Hsd@xps13>
In-Reply-To: <2505996.o0gdCe9Hsd@xps13>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [163.33.239.182]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Thu, 01 Dec 2016 22:31:46 -0000
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, December 1, 2016 20:52
> To: Kulasek, TomaszX <tomaszx.kulasek@intel.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> olivier.matz@6wind.com; Richardson, Bruce <bruce.richardson@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation
>=20
> 2016-12-01 19:20, Kulasek, TomaszX:
> > Hi Thomas,
> >
> > Sorry, I have answered for this question in another thread and I missed
> about this one. Detailed answer is below.
>=20
> Yes you already gave this answer.
> And I will continue asking the question until you understand it.
>=20
> > > 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=3D1024
> > > > > CONFIG_RTE_LIBRTE_IEEE1588=3Dn
> > > > > CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=3D16
> > > > > CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=3Dy
> > > > > +CONFIG_RTE_ETHDEV_TX_PREPARE=3Dy
> > > >
> > > > 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.
> >
> > tx_prepare mechanism can be turned off by compilation flag (as discusse=
d
> with Jerin in http://dpdk.org/dev/patchwork/patch/15770/) to provide real
> NOOP functionality (e.g. for low-end CPUs, where even unnecessary memory
> dereference and check can have significant impact on performance).
> >
> > Jerin observed that on some architectures (e.g. low-end ARM with
> embedded NIC), just reading and comparing 'dev->tx_pkt_prepare' may cause
> significant performance drop, so he proposed to introduce this
> configuration flag to provide real NOOP when tx_prepare functionality is
> not required, and can be turned on based on the _target_ configuration.
> >
> > For other cases, when this flag is turned on (by default), and
> tx_prepare is not implemented, functional NOOP is used based on compariso=
n
> (dev->tx_pkt_prepare =3D=3D NULL).
>=20
> So if the application call this function and if it is disabled, it simply
> won't work. Packets won't be prepared, checksum won't be computed.
>=20
> I give up, I just NACK.
It is not to be turned on/off whatever someone wants, but only and only for=
the case, when platform developer knows, that his platform doesn't need th=
is callback, so, he may turn off it and then save some performance (this op=
tion is per target).
For this case, the behavior of tx_prepare will be exactly the same when it =
is turned on or off. If is not the same, there's no sense to turn it off. T=
here were long topic, where we've tried to convince you, that it should be =
turned on for all devices.
Tomasz