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 89BDCA034E; Fri, 4 Mar 2022 18:32:37 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 26E5D427CA; Fri, 4 Mar 2022 18:32:37 +0100 (CET) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by mails.dpdk.org (Postfix) with ESMTP id 6161E427A9 for ; Fri, 4 Mar 2022 18:32:35 +0100 (CET) Received: by mail-pf1-f178.google.com with SMTP id a5so8151239pfv.9 for ; Fri, 04 Mar 2022 09:32:35 -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=AbX6myoX+jHzSwlMUHyQ+ngwOnd3hAV3opMdcX75COw=; b=2x88lCTyA4ZCzCw/ySrUsfrKy1Jec68ItK8scoZeUzxZ21kqD6AbMkqTJOL98itdpo MdHUCsaCjUb53uRNPR9SMqIxV77zS9mRFBVqsbVRofr99e0DEqB8S+kocPN93u10d4Nw cc0eNkfxszY0WWVb4qYBEQHDvqXeTscFF9Fvwg/pEn0Z7R3NEaoCLO2EhzaexwvXxxtd D9P2IWeTW6j30QXJEDdOKRvSMy7/h8UIo/ufOtkEZMUx98whfuP/FEkVaZm1RqeoCghJ /xc2ZzkMhUgkWzJRSM1/QFKGajxnxYIv8AKJhqy1bdvHWPUmQVIi843b0jMbEBjfeGnN YQCQ== 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=AbX6myoX+jHzSwlMUHyQ+ngwOnd3hAV3opMdcX75COw=; b=D47rbpRZpTFjvJMH1aq9NAvCo4n604eR69V/4+BlVZOWsM/owCwQ1H6KsohxutQddm m6I2gQAqn7w6wBOCDxMeYV0DjGkVoIXSTxfrMM6zV1rey33WNfzvb4WZFSEeFR5r6koK 0aU9m1hERIhsfuyuqBap6RG0JZ2nvFjJZkRMqz5QEfkN/Kn4dXZgB59F0MnIBJKThNnJ vcpWngfeYdOKCQ9YtcS+qkbW3LjTGfQTYnrP8M+sf60yF8Sjpop0vibawCkUW9nWr8Gk D6M+U3XgCU+I4bkKmMTzPPKJ0DwwCnYTb7TWycP9uXWaq16knw0zJtuUke1RcZxQCIMW TuFg== X-Gm-Message-State: AOAM530Q0VQduVuBEfN03zZNaMPpCwP0kV/IK19UxCI8V6QoJCT8fkuJ ia8XSZSJikyJdMa/GRmPDjaLyg== X-Google-Smtp-Source: ABdhPJyx17s/0hvOUF+tSlQVS11eEmv8dNWGDrp0/qWUduNge7kKKVxrKI4BApAwV7LH1AwkbC+94Q== X-Received: by 2002:a05:6a00:ccd:b0:4f1:15bd:2d94 with SMTP id b13-20020a056a000ccd00b004f115bd2d94mr44494200pfv.49.1646415154328; Fri, 04 Mar 2022 09:32:34 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id q10-20020a056a00084a00b004f26d3f5d8fsm6216180pfk.25.2022.03.04.09.32.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Mar 2022 09:32:33 -0800 (PST) Date: Fri, 4 Mar 2022 09:32:27 -0800 From: Stephen Hemminger To: "Zhang, Qi Z" Cc: "Ding, Xuan" , "thomas@monjalon.net" , "Yigit, Ferruh" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" , "viacheslavo@nvidia.com" , "Yu, Ping" , "Wang, YuanX" Subject: Re: [RFC] ethdev: introduce protocol type based header split Message-ID: <20220304093227.461a6d66@hermes.local> In-Reply-To: References: <20220303060136.36427-1-xuan.ding@intel.com> <20220303081539.1de139f9@hermes.local> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, 4 Mar 2022 09:58:11 +0000 "Zhang, Qi Z" wrote: > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Friday, March 4, 2022 12:16 AM > > To: Ding, Xuan > > Cc: thomas@monjalon.net; Yigit, Ferruh ; > > andrew.rybchenko@oktetlabs.ru; dev@dpdk.org; viacheslavo@nvidia.com; > > Zhang, Qi Z ; Yu, Ping ; Wang, > > YuanX > > Subject: Re: [RFC] ethdev: introduce protocol type based header split > > > > 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). > > Yes, agree, that's a mistake there is no document for the reserved field in the previous release, and usually, it should be zero, > And I think one of the typical purposes of the reserved field is to make life easy for new feature adding without breaking ABI. > So, should we just take the risk as I guess it might not be a big deal in real cases? There is a cost/benefit tradeoff here. Although HW vendors would like to enable more features, it really is not that much of an impact to wait until next LTS for users. Yes, the API/ABI rules are restrictive, but IMHO it is about learning how to handle SW upgrades in a more user friendly manner. It was hard for the Linux kernel to learn how to do this, but after 10 years they mostly have it right. If this were a bug (especially a security bug), then the rules could be lifted.