From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 3A609A04A2;
	Thu,  3 Mar 2022 17:15:45 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id C23784276B;
	Thu,  3 Mar 2022 17:15:44 +0100 (CET)
Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com
 [209.85.215.169])
 by mails.dpdk.org (Postfix) with ESMTP id 30FD440687
 for <dev@dpdk.org>; Thu,  3 Mar 2022 17:15:43 +0100 (CET)
Received: by mail-pg1-f169.google.com with SMTP id w37so4931378pga.7
 for <dev@dpdk.org>; Thu, 03 Mar 2022 08:15:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
 h=date:from:to:cc:subject:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=3bCqbin4AUeNh8fJD6Vxg8bofruX6zrIwUP5yi/vPTk=;
 b=kRML3Vir7py5FBWL6POY6esjgnsOgrSehzikJcb1sAHhdKNLKqfIt9mo/fjMaMLTNB
 IaxXeLKprc8WM82EX1FRPpG5p1MPns/JwZ79W0RZBM1ggahg7pOWS+/PmZ0AkCbLczVb
 KAoPn3XwgT5120P67cDKfTxk9Wl59nP1cLrxMfrazva8UbEjNePauFEg586RIqTafRzE
 aYXSUCcla+DFGWT18dpMD76XTRDPQbUE4xfVWivuVgpTzHpuzgu+YVGZln8JNKhNWC3p
 gkwbGAW0D3jAVaplR7Gzci1I4LtvDniwNEaRHRHniBFH4ukp9sFX5aJeYE/hpubVIODf
 /xyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=3bCqbin4AUeNh8fJD6Vxg8bofruX6zrIwUP5yi/vPTk=;
 b=yXSu1tKkattJszJfcw2FuZT2M1ckNrSdHOB0zKzL82vk7TY8givf+nNunbeodqSFzC
 Lpa4vjbxJZ+LrS+rij9ArII8Fwd6qwZbWlXeNR4EdUE7edgO+M5VY/hE/D1uyjPzoZEm
 9pCDe4RCZ4AkAAfIjcpvvveUf6cqaMOWz/wU4dJ1A8v3uY9yt3QFrzrYPWEjsOW1kQ7o
 kP2k98XboRkmm/A1NYiscexlL2rmyNeWagmbl3egx/0kjwW8AIpaurNODhB5sAoun8nr
 9HQf1gBmsk6c7GWal3dkwywoKkoupM2wrXMEshujnU1gQlnVWgBUnivNTsv60Z8AbsvB
 AuZA==
X-Gm-Message-State: AOAM533eNAf/6b3tTKkn34CQ0ZA7/2MgKUrB6mW9B2oodHyirsQllJXd
 4tNSTWZ6K115bWVhG3u5atI5Sg==
X-Google-Smtp-Source: ABdhPJzfaaGxjqqj1AKlif+xbrgLHumVFJpg8F5Byv3T7buuVIvubw49soMh2+HOq/E1FGFQHjOmnQ==
X-Received: by 2002:a63:131c:0:b0:378:c369:67d5 with SMTP id
 i28-20020a63131c000000b00378c36967d5mr15336959pgl.149.1646324142123; 
 Thu, 03 Mar 2022 08:15:42 -0800 (PST)
Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199])
 by smtp.gmail.com with ESMTPSA id
 u15-20020a056a00124f00b004f12b8c81ccsm2890917pfi.75.2022.03.03.08.15.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 03 Mar 2022 08:15:41 -0800 (PST)
Date: Thu, 3 Mar 2022 08:15:38 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: xuan.ding@intel.com
Cc: thomas@monjalon.net, ferruh.yigit@intel.com,
 andrew.rybchenko@oktetlabs.ru, dev@dpdk.org, viacheslavo@nvidia.com,
 qi.z.zhang@intel.com, ping.yu@intel.com, Yuan Wang <yuanx.wang@intel.com>
Subject: Re: [RFC] ethdev: introduce protocol type based header split
Message-ID: <20220303081539.1de139f9@hermes.local>
In-Reply-To: <20220303060136.36427-1-xuan.ding@intel.com>
References: <20220303060136.36427-1-xuan.ding@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Thu,  3 Mar 2022 06:01:36 +0000
xuan.ding@intel.com wrote:

> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index c2d1f9a972..6743648c22 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1202,7 +1202,8 @@ struct rte_eth_rxseg_split {
>  	struct rte_mempool *mp; /**< Memory pool to allocate segment from. */
>  	uint16_t length; /**< Segment data length, configures split point. */
>  	uint16_t offset; /**< Data offset from beginning of mbuf data buffer. */
> -	uint32_t reserved; /**< Reserved field. */
> +	uint16_t proto;
> +	uint16_t reserved; /**< Reserved field. */
>  };

This feature suffers from a common bad design pattern.
You can't just start using reserved fields unless the previous versions
enforced that the field was a particular value (usually zero).

There is no guarantee that application will initialize these reserved
fields and now using them risks breaking the API/ABI. It looks like

rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split *rx_seg,

Would have had to check in previous release.

This probably has to wait until 22.11 next API release.