From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=rMwmiixnL9A7ONcQSReBbfjTWFD9YikLqBasMBkiPVU=; b=h9k5Uqfkgp2lbJKPgSf4CDKfPypjFXyA3EDZDpeGAZ26kiqxHMK/3dMyu37UoDjn3e 6THRHH+kOhbiiRH0DWUraMWazpDHifIAsP/lp6cW/38pSf3W+XeQ+lNL+Obe4LbCtEsa q23wH//v11R11W+8EF/l2dYQkTnzOz43W+35kHwuABlEbhmeEkTEEkCtWEtQS3nQ/xws RJvCX1cqQzs85pdOnHWyMz4x0RNHl1DeO4n9UxpY0HRDSN41DbNXjx/bS66PAFLjk9Th C9NUgCoyYJgoYIqK9ymngEB8eK5rCMjNLz6PyT/q1TVi2jO33VMoj+6VES01aDrd+Wx+ Zv6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=rMwmiixnL9A7ONcQSReBbfjTWFD9YikLqBasMBkiPVU=; b=EpunQkm0LEAvcrUcww1826VYHbkOgqR/qrXGoFLKkPxrWtENpenfYtp6cB5U0jJKvl 5vRpG7S4R1xd+HNeN0dRgin4hGwBJH+nZqSa6W54WH6qsOPG7XwikrKkzLfZJBYztCdB +HwMrw59wqcqmMB+o8Pg5YqUV+fexUipuZuAYzJ7UB2ffs3LWTBrjixGqq3WiBEdhdSc xgJAGg1TdaHAg9Rpkb520e4EHYY6OKQemCYuV0jxPHq8vZuMZnZtI2C5/hr8dspUVAR1 m6En1tk17vCXBjyEs6VHNKlTHsu6QNwjZSiejoCfqpD5762jxUvfs2LmwA6la5PK2IAi eixg== X-Gm-Message-State: AEkoousj94p8X+BsnpLqOpC8lH1DKr3qyb/eRkLuHKfDxKnBBPCbyXIk5tJpNijemSdmQJG8 X-Received: by 10.194.29.102 with SMTP id j6mr33462849wjh.99.1469725662215; Thu, 28 Jul 2016 10:07:42 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id va3sm12437287wjb.18.2016.07.28.10.07.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jul 2016 10:07:41 -0700 (PDT) From: Thomas Monjalon To: Jerin Jacob , "Ananyev, Konstantin" , Tomasz Kulasek Cc: dev@dpdk.org Date: Thu, 28 Jul 2016 19:07:40 +0200 Message-ID: <8304272.tp9pdnokda@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160728162539.GA20918@localhost.localdomain> References: <2601191342CEEE43887BDE71AB97725836B80AD8@irsmsx105.ger.corp.intel.com> <10424266.8Zbn7T9jv8@xps13> <20160728162539.GA20918@localhost.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 17:07:42 -0000 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.