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 E4600A04DB; Thu, 15 Oct 2020 14:49:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 572521E55F; Thu, 15 Oct 2020 14:49:36 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 838D41D5D0 for ; Thu, 15 Oct 2020 14:49:34 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0A5225C01D9; Thu, 15 Oct 2020 08:49:33 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 15 Oct 2020 08:49:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= ZSNrXhS0WDSoMN2WMNYO7/IJWackyufe8fKEo6t1ODU=; b=iQKiTImq1H6v1FW1 AHaUDW2pZG8HkR6WpzKJv6kOsFMwrsXo4NuO/bphu+WehjfYrDh/Kx8Tt8RaDUm6 0ZuKhkgGr7v9FtuZXbdH11gAIVgHHJOlH5JjwwGimfGHSqfB8hlun1e7/WXfbG77 Uo40PrmfG79UDdZhL0CUn/4qHT1sqDAipieCMvCcEbRLBfk/OZxLrEuB3yUMtJ2c c13HJaT6qvfNDMs4A2WTegdTHHNDPsu5RTpODLnbMLmc02rGQWcrH34Mt9KmnP86 QVA2FhPuzPv40Mw7lp2n0C6fFaVjAIGrDq+u9Fs1rHHh3SGOl/OTl6OIELm1H7Mb kQL4KA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ZSNrXhS0WDSoMN2WMNYO7/IJWackyufe8fKEo6t1O DU=; b=GSqs0T70xZtkjDQ5Ulm0JIe5fQupvnOs48/q0bzQbxVjMpw+xkbB5m7xM J4dtcAIoYFpIbo7Mr6838BEVfMobGtYzyP2F8OX/PaGPT/4I78BqGGf4YAJqm467 nHTY5PmhIeDHHnFkONhCfmS0TNIPUGMXUS7du0yEDGNVFgQUw8LwcUC4QtsoZe+q bCK4Vd4qbAbAm0ckaZjKePyVYbnxuA6ez/WK1DqG1yqx4tQuHgGcm//LAIiP8E/l eCegiC8PKgB3esCuEg4VeZsJQizBvD1qhIAtI0pGHgvXbuwg5jo4/GHuHBgywUfR UTJyNnAV9V+ZmFoW7l0WsDrfHFifw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieefgdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3138C3280066; Thu, 15 Oct 2020 08:49:31 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , Jerin Jacob , Slava Ovsiienko , Andrew Rybchenko Cc: dpdk-dev , Stephen Hemminger , Olivier Matz , Maxime Coquelin , David Marchand Date: Thu, 15 Oct 2020 14:49:29 +0200 Message-ID: <3799210.WVtpHuTWyK@thomas> In-Reply-To: References: <87d51011-14df-41cb-2601-ca2fd00de4e0@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split 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" 15/10/2020 13:49, Slava Ovsiienko: > From: Ferruh Yigit > > On 10/15/2020 12:26 PM, Jerin Jacob wrote: > > > > <...> > > > > >>>>> If we see some of the features of such kind or other PMDs adopts > > >>>>> the split feature - we'll try to find the common root and consider > > >>>>> the way how > > >>> to report it. > > >>>> > > >>>> My only concern with that approach will be ABI break again if > > >>>> something needs to exposed over rte_eth_dev_info(). > > >> > > >> Let's reserve the pointer to struct rte_eth_rxseg_limitations in the > > >> rte_eth_dev_info to avoid ABI break? > > > > > > Works for me. If we add an additional reserved field. > > > > > > Due to RC1 time constraint, I am OK to leave it as a reserved filed > > > and fill meat when it is required if other ethdev maintainers are OK. > > > I will be required for feature complete. > > > > > > > Sounds good to me. OK for me. > OK, let's introduce the pointer in the rte_eth_dev_info and > define struct rte_eth_rxseg_limitations as experimental. > Will it be allowed to update this one later (after 20.11)? > Is ABI break is allowed for the case? If it is experimental, you can change it at anytime. Ideally, we could try to have a first version of the limitations during 20.11-rc2.