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 CFD6CA0C44; Mon, 14 Jun 2021 18:36:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5B0EA4067E; Mon, 14 Jun 2021 18:36:25 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 0D7754067A for ; Mon, 14 Jun 2021 18:36:24 +0200 (CEST) Received: from [192.168.1.71] (unknown [188.170.85.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 2079A7F52A; Mon, 14 Jun 2021 19:36:23 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 2079A7F52A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1623688583; bh=KS9KKzRaC5LWF0R1GbP0VLPX5o5MV9J2KesQDmZy7o4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=MdWIrPMUHElYtbWi6bLXWeNXfoQeDUgmyNtmysdkmN5HjgTCEZ1hrLNMhAhMYgDbU ssRBL+TabJ9MqZ7vpi4oaJLrUpL+f18EGYPdDUF1txfTZRL40f7dC4Rx7xThNkcoL/ QCTI6cwU/3P4ku3MEiONeowai1sunocIAgZkjlyk= To: 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 , Ferruh Yigit References: <20210527152858.13312-1-getelson@nvidia.com> <98CBD80474FA8B44BF855DF32C47DC35C617E2@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C617E6@smartserver.smartshare.dk> From: Andrew Rybchenko Message-ID: Date: Mon, 14 Jun 2021 19:36:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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/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. 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 >