From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id C177D5F2E for ; Sat, 9 Jun 2018 02:24:51 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id l15-v6so4055802wmc.1 for ; Fri, 08 Jun 2018 17:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=CGx2bMCWMLPSpaNQkwxf0Kv61z+D9SLqdu8q7OOns0o=; b=pHk39Of7o3ypNEAaAEIj7bUH+VHkCe32FRsIg4TLSAR2htFVi6wAAktgGT2czEm0BL sCWL5zkETtzrhb6D7CuVbad67fG4hjSCLUUpSycYOKL8t4UN+npcRdsHCOq3k3Jmxt6q FWOUFbg7QK+bdhdCx0TYiA3to8I+W8qj3xCkwIn84SpbGm6bZtrWgmha0HEWr90TBao7 5Azw4u4BRZtpaD9yHyL1yEZ9v5H4HmD2T5jNnWmZbGmhhRcBgf9ifbR/UG1cuxcV9J+k xpVpbw5j/e8aAIYJg2U0WJF1R+wA09lzS4utOZ3Zaq8M1UeN9PL6dOuPoENPs34fpjMl PGMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=CGx2bMCWMLPSpaNQkwxf0Kv61z+D9SLqdu8q7OOns0o=; b=oXJjt7h2Dod05N/O4rrZojb3BAHkRmIs3PDCVz1Y1ZIviLwviLPiZCrYarT1XyBonx ZK/Wloa0tQizn/hCTtayBTAzKmibWAjmNDHOxQfqRJE+GlCUWyNZXs3hvqVx2fCy/Fyh dUNT7m9iaqlu9lFvIxFvGnDiWwKtJ91sb8GsuK6+CaAFJ1cfz5wx7nPx0GZz9FI+LZnT MuM9D7gwJ31rZuR9FxdrY9vGF5/OmkZZivl/SNMOVsv06CeJ7Wz+gbNkoy21VvuiIMnN Tu5iE2f4/jTIE+puUrMhSop1vzfDNsA/gTaxkbonbcvkssXwa8agJm4rZ72U7u0CppEZ i2JQ== X-Gm-Message-State: APt69E0wruFV5fn9otoC5iEk1x2cR/noXSktZSDqLVnbb9D43z/wBjnL z0wEQBIFPAVyj/ahrSXCHdN3Rj0zC8n7m/YH20s= X-Google-Smtp-Source: ADUXVKLvityLRAw0YPvim9gUGSmSuXyjs5ELI3VZkqqAhmJRZGob/nyRc0F7HxkFKxwWZAVGIhXl8qHqX4bB0zzjra0= X-Received: by 2002:a1c:ae0c:: with SMTP id x12-v6mr2953003wme.133.1528503891246; Fri, 08 Jun 2018 17:24:51 -0700 (PDT) MIME-Version: 1.0 Sender: dan.gora@gmail.com Received: by 2002:adf:e952:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 17:24:10 -0700 (PDT) In-Reply-To: <5F1328F1-6991-45EA-8DC2-300600702210@intel.com> References: <20180607235454.27832-1-dg@adax.com> <99f224eb-0470-78d2-a062-8dca4d4b7b1a@solarflare.com> <5F1328F1-6991-45EA-8DC2-300600702210@intel.com> From: Dan Gora Date: Fri, 8 Jun 2018 21:24:10 -0300 X-Google-Sender-Auth: liypq--G46vDt_paTlr8mTxlOZk Message-ID: To: "Wiles, Keith" Cc: Andrew Rybchenko , "dev@dpdk.org" , Olivier Matz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH 1/4] mbuf: add accessor function for private data area 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: , X-List-Received-Date: Sat, 09 Jun 2018 00:24:51 -0000 Hi All, Thanks for the feedback. >> Just a nit... >> As I understand 'md' here follows previous function which is >> rte_mbuf_to_baddr() and works with direct mbuf - that's why >> parameter is named 'md' (mbuf direct). The most of functions >> in the header use just 'm' for any mbuf. Ok, I'll fix this for v2. >>> +{ >>> + if (md->priv_size =3D=3D 0) >>> + return NULL; >>> + >>> + return RTE_PTR_ADD(md, sizeof(struct rte_mbuf)); >> >> Also a nit... >> I'd use sizeof(*md) (or sizeof(*m) in fact as described above) here. >> At least previous functions do it in such way. > > I believe the sizeof(struct rte_mbuf) is much more readable then sizeof(*= m) it makes the reader have to look up what =E2=80=98m=E2=80=99 is defined = to. I know this is a small function, but readability is still a good reason= to not use sizeof(*m) IMO. On one hand, using sizeof(*m) is useful in case the type of 'm' ever changes, you don't have to remember to change the arguments to sizeof. On the other hand, it does make it slightly harder to read, but not a lot really. For me, it's six one way, half a dozen the other. I just cut-pasted this from the ipsec-secgw code. I'm kind of inclined to leave it sizeof(struct rte_mbuf) just to leave it clear. Any opinion on my question from the cover letter? Specifically when should rte_mbuf_XXX be used vs rte_pktmbuf_XXX for mbuf API functions? Why is there this inconsistency there? Are they just historical names which couldn't get changed? One more quick question: When sending a v2 of a patch series, should I resend the whole bundle, even if there are no changes in the other patches or just send a v2 of the patch which actually contains changes from the v1 version? thanks dan