From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2] doc: announce ABI change for rte_eth_dev structure Date: Thu, 28 Jul 2016 19:07:40 +0200 Message-ID: <8304272.tp9pdnokda@xps13> References: <2601191342CEEE43887BDE71AB97725836B80AD8@irsmsx105.ger.corp.intel.com> <10424266.8Zbn7T9jv8@xps13> <20160728162539.GA20918@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Jerin Jacob , "Ananyev, Konstantin" , Tomasz Kulasek Return-path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 825A12BB9 for ; Thu, 28 Jul 2016 19:07:42 +0200 (CEST) Received: by mail-wm0-f46.google.com with SMTP id i5so117564977wmg.0 for ; Thu, 28 Jul 2016 10:07:42 -0700 (PDT) In-Reply-To: <20160728162539.GA20918@localhost.localdomain> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2016-07-28 21:55, Jerin Jacob: > 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. I totally agree with you and it was my first comment in this thread: http://dpdk.org/ml/archives/dev/2016-July/044366.html Unfortunately it is difficult to have a formal process so it is not so strict currently. You are welcome to suggest how to improve the process for the next releases. > 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? I feel the tx_prep can be interesting to solve a current problem. However, as you say, there are maybe other solutions to consider. That's why I think we can keep this deprecation notice and follow up with a patch-based discussion. We will be able to discard this change if something better is found. As an example, we have just removed a deprecation notice which has never been implemented: http://dpdk.org/browse/dpdk/commit/?id=16695af340 I know this process is not perfect and the ethdev API is far from perfect, so we must continue improving our process to define a good API. Konstantin, Tomasz, I generally prefer waiting for a consensus. For this case, I'll make an exception and apply the deprecation notice. Please make an effort to better explain your next patches and meet a clear consensus. We'll review your patches very carefully and keep the right to reject them.