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 43510A052B; Fri, 31 Jul 2020 17:24:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 86E6B262E; Fri, 31 Jul 2020 17:24:48 +0200 (CEST) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id C1B162629 for ; Fri, 31 Jul 2020 17:24:46 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id a15so28337160wrh.10 for ; Fri, 31 Jul 2020 08:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=B4V+Qy0Y93P4zjBQNNnJZF3ONI2Efm0Yq8AQhlcRfYs=; b=P9TITVO/XnDjzLGu3ZmNW8FXchVkbDv5ZQaL6tzjE0ZCTVlNhMq631c6G6x7aDkw12 Xc/JCpb5N1fqDAhwDSKuKU8MsDkDoijuv6JL+4quYRRLsy6fOLqDVTDuGNihQpRHNnLM AwO8iTXAXO/RjQhi2lvgQNcPQh4zI97kuv9ddi+bz5kk2YNDm1jyNdMDUhTCn3FqtiJE XzIfBrEMg1MB2s88xS73ciHfsfeSSM/aLhiqrMQR68suM8tDY2PUp7HtcMngoLo1NFzM K8A8K7/kydUnJOeM47eurTSbMXN0g7KsS4rbZrdyv+W2vejTljkwBlohiC6UP08VKf8E YJXw== 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:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=B4V+Qy0Y93P4zjBQNNnJZF3ONI2Efm0Yq8AQhlcRfYs=; b=tdqGez4yrC0NrZC6bESkMqQE1NCfYN0YjIf0YRGJIEz66Edz16DqU06d7SKK0HpmHa Eyb4AbQGLdlLjGx2008QMKaYPgLTRzgcxL2h6I7aLmHhIkseI3Zscrjs6W/8zfR+IaIw SxdDLqYwalbjMuno4kfGCN7goJmS03XKLeR5cIMzCty1JOF4u9OvSX9SHSVRaOen6CGb Y9jFMZGa3vPsvCwLq00FviFJ7Wj0wj2LYtrAq95E1o9DZt7+FRAPDX3OLsZAud6IDfp9 7T0QwqkN/iD0hmUT3bqHkE3mwnhtv5N0F4hElm+Gi9isRj2cLIz+ugQkcwrMMqD00tJe QCsA== X-Gm-Message-State: AOAM532FXhX1JO6mN7WTMYpn3WH+DUTnPDmoSnxRNYO3/1gLU7ht9E7s XdiVopuXEVZTVydfbzBupC1b751A4aM= X-Google-Smtp-Source: ABdhPJxh/ZCOnLRaPdtOkYYNH6iTEz0FO1iihCIEIqxkFGrcTpUngqudh36RT3fZ06gbZZDmcPoG1A== X-Received: by 2002:adf:d092:: with SMTP id y18mr3787549wrh.145.1596209086560; Fri, 31 Jul 2020 08:24:46 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id z7sm12242086wmk.6.2020.07.31.08.24.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2020 08:24:45 -0700 (PDT) Date: Fri, 31 Jul 2020 17:24:44 +0200 From: Olivier Matz To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org Message-ID: <20200731152444.GI5869@platinum> References: <98CBD80474FA8B44BF855DF32C47DC35C6111E@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C6111E@smartserver.smartshare.dk> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] The mbuf API needs some cleaning up 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" Hi Morten, Thanks for the feedback. On Mon, Jul 13, 2020 at 11:57:38AM +0200, Morten Brørup wrote: > The MBUF library exposes some macros and constants without the RTE_ prefix. I > propose cleaning up these, so better names get into the coming LTS release. Yes, Thomas talked about it some time ago and he even drafted a patch to fix it. We can target 20.11 for the changes, but I think we'll have to keep a compat API until 21.11. > The worst is: > #define MBUF_INVALID_PORT UINT16_MAX > > I say it's the worst because when we were looking for the official "invalid" > port value for our application, we didn't find this one. (Probably because its > documentation is wrong.) > > MBUF_INVALID_PORT is defined in rte_mbuf_core.h without any description, and > in rte_mbuf.h, where it is injected between the rte_pktmbuf_reset() function > and its description, so the API documentation shows the function's description > for the constant, and no description for the function. The one in rte_mbuf_core.h should be kept, with a documentation. > I propose keeping it at a sensible location in rte_mbuf_core.h only, adding a description, and renaming it to: > #define RTE_PORT_INVALID UINT16_MAX I suggest RTE_MBUF_PORT_INVALID > For backwards compatibility, we could add: > /* this old name is deprecated */ > #define MBUF_INVALID_PORT RTE_PORT_INVALID > > I also wonder why there are no compiler warnings about the double definition? If the value is the same, the compiler won't complain. > There are also the data buffer location constants: > #define EXT_ATTACHED_MBUF (1ULL << 61) > and > #define IND_ATTACHED_MBUF (1ULL << 62) > > > There are already macros (with good names) for reading these, so > simply adding the RTE_ prefix to these two constants suffices. Some applications use it, we also need a compat here. > And all the packet offload flags, such as: > #define PKT_RX_VLAN (1ULL << 0) > > > They are supposed to be used by applications, so I guess we should > keep them unchanged for ABI stability reasons. I propose RTE_MBUF_F_ for the mbuf flags. > And the local macro: > #define MBUF_RAW_ALLOC_CHECK(m) do { \ > > This might as well be an internal inline function: > /* internal */ > static inline void > __rte_mbuf_raw_alloc_check(const struct rte_mbuf *m) > agree, I don't think a macro is mandatory here Thanks, Olivier > Or we could keep it a macro and move it next to > __rte_mbuf_sanity_check(), keeping it clear that it is only relevant when > RTE_LIBRTE_MBUF_DEBUG is set. But rename it to lower case, similar to the > __rte_mbuf_sanity_check() macro. > > > Med venlig hilsen / kind regards > - Morten Brørup >