From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2351DA0C4A; Thu, 17 Jun 2021 18:30:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AD0034067A; Thu, 17 Jun 2021 18:30:09 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 127D240150 for ; Thu, 17 Jun 2021 18:30:07 +0200 (CEST) IronPort-SDR: II08im8gTePouI3vX68DdCQiMhnqG0Q2i5PkWMOETAQxjRQJjX3Xh3fHxcNhuLv6d1OCakd+l+ 6/uBlc4LRDlw== X-IronPort-AV: E=McAfee;i="6200,9189,10018"; a="267550258" X-IronPort-AV: E=Sophos;i="5.83,281,1616482800"; d="scan'208";a="267550258" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2021 09:29:48 -0700 IronPort-SDR: GGD2ekeL3WowA069wW1Yt1x7W+rT9EfLdTrV2qNZHx6wGTbF8uTUU98DyDiA4VTcgmitONko75 uKZalYuDZRsg== X-IronPort-AV: E=Sophos;i="5.83,281,1616482800"; d="scan'208";a="554451095" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.201.111]) ([10.213.201.111]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2021 09:29:35 -0700 To: Andrew Rybchenko , Olivier Matz , Gregory Etelson Cc: "Iremonger, Bernard" , =?UTF-8?Q?Morten_Br=c3=b8rup?= , "dev@dpdk.org" , Matan Azrad , Ori Kam , Raslan Darawsheh , Asaf Penso , Thomas Monjalon References: <20210527152858.13312-1-getelson@nvidia.com> <98CBD80474FA8B44BF855DF32C47DC35C617E2@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C617E6@smartserver.smartshare.dk> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Thu, 17 Jun 2021 17:29:31 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] net: introduce IPv4 ihl and version fields X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 6/14/2021 5:36 PM, Andrew Rybchenko wrote: > On 6/10/21 12:22 PM, Olivier Matz wrote: >> Hi Gregory, >> >> On Thu, Jun 10, 2021 at 04:10:25AM +0000, Gregory Etelson wrote: >>> Hello, >>> >>> There was no activity that patch for a long time. >>> The patch is marked as failed, but we verified failed tests and concluded >>> that the failures can be ignored. >>> https://patchwork.dpdk.org/project/dpdk/patch/20210527152858.13312-1-getelson@nvidia.com/ >>> >>> How should I proceed with this case ? >>> Please advise. >>> >> >> I like the idea of this patch: to me it is more convenient to access to >> these fields with a bitfield. I don't see a problem about using >> bitfields here, glibc or FreeBSD netinet/ip.h are doing the same. >> >> However, as stated previously, this patch breaks the initialization API. > > Very good point. I guess we overlooked it in a number of patches > with fix RTE flow API items to start from corresponding network > headers. We used unions there to avoid ABI breakage, but it looks > like we have broken initialization API anyway. > Hi Andrew, What is broken with the flow API item updates, can you please give a sample? > We should decide if initialization ABI breakage is a show-stopper > for RTE flow API items switching to use network protocol headers. > >> The DPDK ABI/API policy is described here: >> http://doc.dpdk.org/guides/contributing/abi_policy.html#the-dpdk-abi-policy >> >>> From this document: >> >>    The API should only be changed for significant reasons, such as >>    performance enhancements. API breakages due to changes such as >>    reorganizing public structure fields for aesthetic or readability >>    purposes should be avoided. >> >> So to follow the project policy, I think we should reject this path. >> >> Regards, >> Olivier >> >