From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id EE5791B1EA
 for <dev@dpdk.org>; Mon, 14 Jan 2019 16:51:40 +0100 (CET)
Received: from lfbn-1-5920-128.w90-110.abo.wanadoo.fr ([90.110.126.128]
 helo=droids-corp.org)
 by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.89) (envelope-from <olivier.matz@6wind.com>)
 id 1gj4YG-0004W1-9Q; Mon, 14 Jan 2019 16:53:25 +0100
Received: by droids-corp.org (sSMTP sendmail emulation);
 Mon, 14 Jan 2019 16:51:30 +0100
Date: Mon, 14 Jan 2019 16:51:30 +0100
From: Olivier Matz <olivier.matz@6wind.com>
To: David Marchand <david.marchand@redhat.com>
Cc: Andrew Rybchenko <arybchenko@solarflare.com>,
 Yongseok Koh <yskoh@mellanox.com>,
 Shahaf Shuler <shahafs@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>,
 "roszenrami@gmail.com" <roszenrami@gmail.com>,
 Bruce Richardson <bruce.richardson@intel.com>
Message-ID: <20190114155130.ju34dd34toxx7vmd@platinum>
References: <20190109085426.39965-1-yskoh@mellanox.com>
 <20190110183528.42503-1-yskoh@mellanox.com>
 <2934bc73-98e6-643a-0d61-cf7804e1535d@solarflare.com>
 <20190111110332.GA8355@minint-98vp2qg>
 <27206464-dcf0-9871-a797-cb0b9f2ff25d@solarflare.com>
 <20190111115701.GB3336@bricha3-MOBL.ger.corp.intel.com>
 <CAJFAV8yVnwfwvpRvW1U6XfrF7VsMKW3xndL1q_JyB4qyJXD7AA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJFAV8yVnwfwvpRvW1U6XfrF7VsMKW3xndL1q_JyB4qyJXD7AA@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [dpdk-dev] [PATCH v3 1/2] mbuf: add function returning default
 buffer address
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jan 2019 15:51:41 -0000

Hi,

On Fri, Jan 11, 2019 at 01:48:12PM +0100, David Marchand wrote:
> On Fri, Jan 11, 2019 at 12:57 PM Bruce Richardson <
> bruce.richardson@intel.com> wrote:
> 
> > On Fri, Jan 11, 2019 at 02:17:04PM +0300, Andrew Rybchenko wrote:
> > > Olivier, David,
> > >
> > > could you take a look at naming suggested below and share your thoughts.
> > > My fear is that rte_mbuf_buf_addr() is too generic and true for direct
> > mbuf
> > > only. That's why I'd like to highlight it in the function name.
> > >
> >
> > I would tend to agree with that concern.
> >
> 
> I understand your concern as well.
> 
> The only usecase we have so far is for drivers on the rx side, so
> implicitely direct mbufs.
> But from a api user pov, explicit is always better.
> 
> I will let Olivier have the last word :-)

Thanks Andrew for pointing this out.

However I agree with Yongseok: we already have many functions that
applies to direct mbufs that don't have "direct" in their names.

In my opinion, rte_mbuf_buf_addr() is a good name, but I think the
doxygen comment could be improved a bit to state that it returns the
pointer to the embedded data. I also think that a small comment
explaining why the mp arg is required would be helpful.

Thanks,
Olivier