From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH v2] doc: announce ABI change for rte_eth_dev
 structure
Date: Thu, 28 Jul 2016 21:55:40 +0530
Message-ID: <20160728162539.GA20918@localhost.localdomain>
References: <2601191342CEEE43887BDE71AB97725836B80AD8@irsmsx105.ger.corp.intel.com>
 <2601191342CEEE43887BDE71AB97725836B8AB57@irsmsx105.ger.corp.intel.com>
 <20160728135915.GA17655@localhost.localdomain>
 <10424266.8Zbn7T9jv8@xps13>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, <dev@dpdk.org>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM01-BY2-obe.outbound.protection.outlook.com
 (mail-by2nam01on0041.outbound.protection.outlook.com [104.47.34.41])
 by dpdk.org (Postfix) with ESMTP id 2CB5E378B
 for <dev@dpdk.org>; Thu, 28 Jul 2016 18:26:09 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <10424266.8Zbn7T9jv8@xps13>
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>

On Thu, Jul 28, 2016 at 04:52:45PM +0200, Thomas Monjalon wrote:
> 2016-07-28 19:29, Jerin Jacob:
> > Above things worries me, I wouldn't have cared if the changes are not comes
> > in fastpath and I don't think this sort of issues will never get fixed any time
> > soon in this community.
> > 
> > So I given up.
> 
> I feel something goes wrong here but I cannot understand your sentence.
> Please could you reword/explain Jerin?

I guess you have removed the context from the email. Never mind.

1) IMHO, Introducing a new fast path API which has "performance impact"
on existing other PMD should get the consensus from the other PMD maintainers.
At least, bare minimum, send a patch much in advance with the
implementation of ethdev API as well as PMD
driver implementation to get feedback from other developers _before_ ABI
change announcement rather just debating on hypothetical points.

2) What I can understand from the discussion is that it is the
workaround for an HW limitation.
At this point, I am not sure tx_prep is the only way to address it and
do other PMD have similar
restriction?. If yes, Can we have abstract it in a proper way the usage
part will be very clear from PMD and application perspective?

Jerin