From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DD9EDA00E6 for ; Mon, 5 Aug 2019 10:05:52 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BC3941BDE6; Mon, 5 Aug 2019 10:05:52 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 7125A1BDE2 for ; Mon, 5 Aug 2019 10:05:51 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id B9C59BC0067; Mon, 5 Aug 2019 08:05:49 +0000 (UTC) Received: from [192.168.1.11] (85.187.13.152) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 5 Aug 2019 09:05:44 +0100 To: Thomas Monjalon , CC: References: <20190801124123.21591-1-thomas@monjalon.net> From: Andrew Rybchenko Message-ID: Date: Mon, 5 Aug 2019 11:05:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190801124123.21591-1-thomas@monjalon.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [85.187.13.152] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24822.003 X-TM-AS-Result: No-13.802100-8.000000-10 X-TMASE-MatchedRID: X4bcv0S75KnmLzc6AOD8DfHkpkyUphL98t+pfhBMObxs98Z8fG/6kYvl 3ToEz777k0S4IVEcmW0HFegM4rZUqGBVLJ564D+bGLet1ulBcPsO9z+P2gwiBWcBMv0FvtzlPmZ fySg+ZStGyEwcXJJbKvL5cWtbde9AYlldA0POS1IUaS/iLVoC5jFcf92WG8u/4nhkC0SGkySy7L 7OidKx3STBJ4BxdU3h4rrMV2BznIeLtl7R+4Qd0kaMPBFKXyAUFjhMXzZ2iMmNTrsIz649BPo9b ow075aLiK4AoRG6tnDQ6avGafoozsbHCgc+q0y559dTCwxFnaEZSo6PM4Lsik4QgsE4F6YvXgdg A+CEUyhONIAtzBgYjs1B/lt6hTMeDPIzF4wRfrA5f9Xw/xqKXVkMvWAuahr8+gD2vYtOFhgqtq5 d3cxkNb46etiJf39rGLGCmSimxGA3pTjMmDUnon7TorfcsmADf03G3qxTrAY= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--13.802100-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24822.003 X-MDID: 1564992350-fcOinieAruaj Subject: Re: [dpdk-dev] [PATCH] doc: announce API change in mbuf X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 8/1/19 3:41 PM, Thomas Monjalon wrote: > In order to prepare for a long term stable API, the mbuf library > has to change: allowing more features as dynamic fields, > and fixing the lack of rte_ prefix in the namespace. > The namespace fix should not break the compatibility by keeping > some aliases during few releases to give time for migration. > > Signed-off-by: Thomas Monjalon > --- > doc/guides/rel_notes/deprecation.rst | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > index 37b8592b6..e4939f1fe 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -51,6 +51,11 @@ Deprecation Notices > structure would be made internal (or removed if all dependencies are cleared) > in future releases. > > +* mbuf: Some fields will be moved or converted to dynamic API in DPDK 19.11 > + in order to offer more space for the dynamic fields in future. > + The namespace will be fixed at the same time while keeping a backward > + compatibility for some time. > + > * ethdev: the legacy filter API, including > ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well > as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR, The deprecation notice is better than nothing, but "some fields" is hardly useful since it doe not provide enough information if an application is affected or not. Also we have no yet information on performance impact of switching to dynamic fields. May be it is not a problem if switching does not happen. I have no strong opinion, just trying to raise my concerns. May be you already have answers on it.