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 1E699A04C1; Wed, 20 Nov 2019 16:56:22 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AE8EF9E4; Wed, 20 Nov 2019 16:56:20 +0100 (CET) Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by dpdk.org (Postfix) with ESMTP id 6003423D for ; Wed, 20 Nov 2019 16:56:19 +0100 (CET) Received: by mail-pf1-f196.google.com with SMTP id n13so14435574pff.1 for ; Wed, 20 Nov 2019 07:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=DaAQeONWCSrOzTmNqIVzy92hJXWGLyCwXfiOdjAB4/8=; b=Vw3gDrk5nxC34zLnuBOYKPhvWu1//1Uj9lRmAOsPiMWliEqtcw3P3W5BiL1Rwiw2HG GJSUsKqjGP6NSdCzsTvYEHRF2gy5ffKQ/BautJLNMcMydIgyClYrFjmBZRjtXPa9Z1qx tSJySzkdcFSLxbyXzfSQWRjKmKczTfWyvCTOofzCtoMv3TIlCiwwx/Xk0esMlHKEuIa2 TZYvfLL03drtzNVbbNetQ19MYTg/LaNT8pjubn7jpLF8z87wYtd7GTmNItiM1Xweuvge 2NVsd+1tcFLTstXn/oR5zHBFSKq9emCzZn5T1W9hazMnxnVaaf/NweUVQPMxza3PqoEn k2rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=DaAQeONWCSrOzTmNqIVzy92hJXWGLyCwXfiOdjAB4/8=; b=ny25sI4RZ5NAmUxB8+WnAnV8TTQ2TvxKhFn6SXmF8GCKGx1QENgG2aMxNhkz6elP+Y NiUZ2eE95pmkUcGEzdgqwHW00I5uw9dmIC6WJQEwBW+XVu/N2GDQq3fHGjuaej6DBD1m VvPfhsbQJSazfKEaEejgLlyjcwgGPLpRZNu4NLaDa0qdfKqctsl5PF4npDDGAjd97lwR HRZ/cTr+gcBjittr1M+a6BDfPJnTB8hUADXM+SwFRrH7QECfaqJ5PViGWwFcWVN60EkD mdZzNb+olsX97UqG6umpd66/8rJJmfSArcjLZUoFj7+exbrueYvGDltSn1/y4fhPHfM1 Feyg== X-Gm-Message-State: APjAAAXU2qR2xZ5lu1M8zEGJ0lbSvreyGLtQypGdKk/KHWWF2QMXXbO2 6mb5R2SBjL4ctuoGV4fGppe9ow== X-Google-Smtp-Source: APXvYqx3iHUJdUTP7gvr+JbsNAXJWHLBCGsc1Wj2ByMVJPNc7NWsXQNmOEBy5WwyTQyz6CV3/k2rrA== X-Received: by 2002:a63:5a5c:: with SMTP id k28mr3972956pgm.183.1574265378246; Wed, 20 Nov 2019 07:56:18 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id c9sm29203969pfn.65.2019.11.20.07.56.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Nov 2019 07:56:17 -0800 (PST) Date: Wed, 20 Nov 2019 07:56:14 -0800 From: Stephen Hemminger To: Shahaf Shuler Cc: Thomas Monjalon , "olivier.matz@6wind.com" , "dev@dpdk.org" Message-ID: <20191120075614.07bf2207@hermes.lan> In-Reply-To: References: <20191118100247.74241-1-shahafs@mellanox.com> <20191119082515.41848e4e@hermes.lan> <2817003.Afhorg6P4o@xps> <20191119155032.78a0180c@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] mbuf: extend pktmbuf pool private structure 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" On Wed, 20 Nov 2019 07:01:26 +0000 Shahaf Shuler wrote: > Wednesday, November 20, 2019 1:51 AM, Stephen Hemminger: > > Subject: Re: [dpdk-dev] [PATCH] mbuf: extend pktmbuf pool private > > structure > > > > On Tue, 19 Nov 2019 23:30:15 +0100 > > Thomas Monjalon wrote: > > > > > 19/11/2019 17:25, Stephen Hemminger: > > > > On Tue, 19 Nov 2019 15:23:50 +0000 > > > > Shahaf Shuler wrote: > > > > > > > > > Tuesday, November 19, 2019 11:33 AM, Thomas Monjalon: > > > > > > Subject: Re: [PATCH] mbuf: extend pktmbuf pool private structure > > > > > > > > > > > > 18/11/2019 11:02, Shahaf Shuler: > > > > > > > struct rte_pktmbuf_pool_private { > > > > > > > uint16_t mbuf_data_room_size; /**< Size of data space in > > each > > > > > > mbuf. */ > > > > > > > uint16_t mbuf_priv_size; /**< Size of private area in each > > mbuf. > > > > > > */ > > > > > > > + uint32_t reserved; /**< reserved for future use. */ > > > > > > > > > > > > Maybe simpler to give the future name "flags" and keep the > > comment > > > > > > "reserved for future use". > > > > > > > > > > I'm am OK w/ changing to flags. > > > > > If Olivier accepts maybe you can change while applying? > > > > > > > > After the Linux openat experience if you want to add flags. > > > > Then all usage of API needs to validate that flags is 0. > > > > > > Sorry Stephen, I don't understand what you mean. > > > Please could you explain? > > > > > > > > > > Any time a new field is added that maybe used later you can not guarantee > > that existing code correctly initializes the value to zero. What happened with > > openat() was that there was a flag value that was originally unused, but since > > kernel did not enforce that it was zero; it could not later be used for > > extensions. > > > > You need to make sure that all reserved fields are initialized. > > That means when a private pool is created it is zeroed. And if a flag is new > > argument to an API, check for zero at create time. > > I guess we can hard code the value for 0 on the rte_pktmbuf_pool_create function and have some assert on the rte_pktmbuf_pool_init callback (we cannot fail as this function returns void). > Any other places you find problematic? No. that should be good.