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 6B308A04C1; Wed, 20 Nov 2019 00:50:39 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F06DBA69; Wed, 20 Nov 2019 00:50:37 +0100 (CET) Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by dpdk.org (Postfix) with ESMTP id 0392C23D for ; Wed, 20 Nov 2019 00:50:36 +0100 (CET) Received: by mail-pl1-f193.google.com with SMTP id j12so12846326plt.9 for ; Tue, 19 Nov 2019 15:50:36 -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=K2A4UipHCs86zTCObeMSjoueZ/SXzS2rBSPd9o4kcBY=; b=PulBWozm2sbVft7GGbrE0kJpF1kkOnrFj63SAfX8T8Kq5hKpAjgFiUcR1V4yBxNP6C 4WW6EqCZj5/47WjlCz+FTsmxeUVqpNrag7PVBuMj/DB/qAEQm6KYMzEp+5fcCuyqJ0sr WYoaLuSSrlE3QHE0V9oCVbF774fx9ACa+rQ3A9B2Jg4aucA4Evm0B/8CV8Z2UCwMkKVy zMaMVTSURUBR19y+PxbhMqnIVG7EGwdZtOhN+zqf+nMbHcBDVvzViWy11/LMLZYAA6w+ 5PO3h+xRd6tv8o4UCEZMTzkN0XsOIinunf7SnH98+nYPT/ioFa4TCCPflvQHnHlCWoGd L/Pg== 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=K2A4UipHCs86zTCObeMSjoueZ/SXzS2rBSPd9o4kcBY=; b=p4xBqtf0CbR8HyR/60SAQ++nz113RC+dhGI8yhTEsYS9pJvVjZod044X19SXDQXhb/ uOIYl9q8iw+3vQD5RHWMIenMql6P20lI9UxDhHbm0bj7cdu5pbOihSrIFdCcFfhzlfwc 2k7sXNDqY0kUmddNHueyoJlpDYkVc3ibxVYDJX6IB3eefngZfnhLpZSpktZL8vw8lFQd SKtnqWr/69dD4EnpH0Sz4UV3u3TV9TNWV5yaUPPTBMNiqp92y3WeWxiyiAE0rsan0Dgs FLFfRrvuyyCcIPjM8FPVeOVVfPIUPKIE58egtpl1Gn9JPfMG/jMQ34A8cmyE2SRXr7rR Gmrw== X-Gm-Message-State: APjAAAW3GfL3jUH9YNlQVCYBFsEEhEI34i1Iq6CMzMMhRZ3ixXev2xHl eUxSkZ/ebieIz8LVCj4XHg+Tbku5uZlLSw== X-Google-Smtp-Source: APXvYqwvEqkNdnv6Q4iraQMeFB3zhojAQyeiKRFif2l1UgRfvEDNEN7faFNzYPjAwcLV7gvtDER2Pw== X-Received: by 2002:a17:90a:b308:: with SMTP id d8mr225922pjr.23.1574207435929; Tue, 19 Nov 2019 15:50:35 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id c12sm28451110pfp.67.2019.11.19.15.50.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Nov 2019 15:50:35 -0800 (PST) Date: Tue, 19 Nov 2019 15:50:32 -0800 From: Stephen Hemminger To: Thomas Monjalon Cc: Shahaf Shuler , "olivier.matz@6wind.com" , "dev@dpdk.org" Message-ID: <20191119155032.78a0180c@hermes.lan> In-Reply-To: <2817003.Afhorg6P4o@xps> References: <20191118100247.74241-1-shahafs@mellanox.com> <20191119082515.41848e4e@hermes.lan> <2817003.Afhorg6P4o@xps> 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 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. An example of how DPDK failed at this is the filter field in rte_pdump. Since it is not checked for NULL, it can't safely be used now (and still claim API/ABI compatiablity).