All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yongseok Koh <yskoh@mellanox.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Cc: "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	Shahaf Shuler <shahafs@mellanox.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"roszenrami@gmail.com" <roszenrami@gmail.com>
Subject: Re: [PATCH v3 1/2] mbuf: add function returning default buffer address
Date: Fri, 11 Jan 2019 11:37:52 +0000	[thread overview]
Message-ID: <49ED7E73-6BB0-46DD-AE49-F39B54E18A30@mellanox.com> (raw)
In-Reply-To: <27206464-dcf0-9871-a797-cb0b9f2ff25d@solarflare.com>


> On Jan 11, 2019, at 3:17 AM, Andrew Rybchenko <arybchenko@solarflare.com> 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.

Like the existing rte_mbuf_to_baddr(), it is to return the buf_addr of
the given mbuf. It doesn't matter whether the given mbuf is direct or not.
It should be used at user's discretion.

Yongseok

> On 1/11/19 2:03 PM, Yongseok Koh wrote:
>> On Fri, Jan 11, 2019 at 11:14:22AM +0300, Andrew Rybchenko wrote:
>> 
>>> On 1/10/19 9:35 PM, Yongseok Koh wrote:
>>> 
>>>> This patch introduces two new functions - rte_mbuf_buf_addr() and
>>>> rte_mbuf_data_addr_default().
>>>> 
>>>> rte_mbuf_buf_addr() reutrns the default buffer address of given mbuf which
>>>> comes after mbuf structure and private data.
>>>> 
>>>> rte_mbuf_data_addr_default() returns the default address of mbuf data
>>>> taking the headroom into account.
>>>> 
>>>> Signed-off-by: Yongseok Koh 
>>>> <yskoh@mellanox.com>
>>>> 
>>>> ---
>>>> 
>>>> v3:
>>>> * rename functions
>>>> 
>>>> v2:
>>>> * initial implementation
>>>> 
>>>>   lib/librte_mbuf/rte_mbuf.h | 43 ++++++++++++++++++++++++++++++++++++++++---
>>>>   1 file changed, 40 insertions(+), 3 deletions(-)
>>>> 
>>>> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
>>>> index bc562dc8a9..486566fc28 100644
>>>> --- a/lib/librte_mbuf/rte_mbuf.h
>>>> +++ b/lib/librte_mbuf/rte_mbuf.h
>>>> @@ -788,8 +788,47 @@ rte_mbuf_from_indirect(struct rte_mbuf *mi)
>>>>   }
>>>>   /**
>>>> + * Return the default buffer address of the mbuf.
>>>> + *
>>>> + * @param mb
>>>> + *   The pointer to the mbuf.
>>>> + * @param mp
>>>> + *   The pointer to the mempool of the mbuf.
>>>> + * @return
>>>> + *   The pointer of the mbuf buffer.
>>>> + */
>>>> +static inline char * __rte_experimental
>>>> +rte_mbuf_buf_addr(struct rte_mbuf *mb, struct rte_mempool *mp)
>>>> 
>>> struct rte_mbuf has pool member. So, I don't understand why mp
>>> argument is required. I guess there is a reason, but it should be
>>> explained in comments. I see motivation in rte_mbuf_to_baddr()
>>> description, but rte_mbuf_buf_add() does not explain it.
>>> 
>> Well, I don't like to put same comment here and there but I'll add small comment
>> here.
>> 
>> 
>>> Also right now the function name looks like simple get accessor for
>>> buf_addr and I'd expect to seem one line implementation may be
>>> with extra debug checks: return mb->buf_addr.
>>> 
>> This func is suggested by David and Olivier because same code is being repeated
>> in multiple locations. This can be used to initialize a mbuf when mb->buf_addr is
>> null. And second use-case (this is my use-case) is to get the buf_addr without
>> accessing the mbuf struct when mempool of mbuf is known, e.g. Rx buffer
>> replenishment. It is definitely beneficial for performance, especially RISC
>> cores.
>> 
>> 
>>> May be rte_mbuf_direct_buf_addr() ?
>>> If so, similar below rte_mbuf_direct_data_addr_default().
>>> 
>> Regarding naming, people have different tastes. As it is acked by Olivier and
>> David, I'll keep the names.
>> 
> 
>> Thanks,
>> Yongseok
>> 
>> 
>>>> +{
>>>> +	char *buffer_addr;
>>>> +
>>>> +	buffer_addr = (char *)mb + sizeof(*mb) + rte_pktmbuf_priv_size(mp);
>>>> +	return buffer_addr;
>>>> +}
>>>> +
>>>> +
>>>> +/**
>>>> + * Return the default address of the beginning of the mbuf data.
>>>> + *
>>>> + * @param mb
>>>> + *   The pointer to the mbuf.
>>>> + * @return
>>>> + *   The pointer of the beginning of the mbuf data.
>>>> + */
>>>> +static inline char * __rte_experimental
>>>> +rte_mbuf_data_addr_default(struct rte_mbuf *mb)
>>>> +{
>>>> +	return rte_mbuf_buf_addr(mb, mb->pool) + RTE_PKTMBUF_HEADROOM;
>>>> +}
>>>> +
>>>> +/**
>>>>    * Return the buffer address embedded in the given mbuf.
>>>>    *
>>>> + * Note that accessing mempool pointer of a mbuf is expensive because the
>>>> + * pointer is stored in the 2nd cache line of mbuf. If mempool is known, it
>>>> + * is better not to reference the mempool pointer in mbuf but calling
>>>> + * rte_mbuf_buf_addr() would be more efficient.
>>>> + *
>>>>    * @param md
>>>>    *   The pointer to the mbuf.
>>>>    * @return
>>>> @@ -798,9 +837,7 @@ rte_mbuf_from_indirect(struct rte_mbuf *mi)
>>>>   static inline char *
>>>>   rte_mbuf_to_baddr(struct rte_mbuf *md)
>>>>   {
>>>> -	char *buffer_addr;
>>>> -	buffer_addr = (char *)md + sizeof(*md) + rte_pktmbuf_priv_size(md->pool);
>>>> -	return buffer_addr;
>>>> +	return rte_mbuf_buf_addr(md, md->pool);
>>>>   }
>>>>   /**
>>>> 
> 

  reply	other threads:[~2019-01-11 11:37 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09  8:54 [PATCH] net/mlx5: fix instruction hotspot on replenishing Rx buffer Yongseok Koh
2019-01-09  9:38 ` David Marchand
2019-01-09  9:52   ` Olivier Matz
2019-01-09  9:56     ` Yongseok Koh
2019-01-09 10:05       ` David Marchand
2019-01-09 10:11         ` Yongseok Koh
2019-01-09 13:19 ` [PATCH v2 1/2] mbuf: add function returning default buffer address Yongseok Koh
2019-01-09 13:19   ` [PATCH v2 2/2] net/mlx5: fix instruction hotspot on replenishing Rx buffer Yongseok Koh
2019-01-09 13:46   ` [PATCH v2 1/2] mbuf: add function returning default buffer address David Marchand
2019-01-10  1:39     ` Rami Rosen
2019-01-10 18:18       ` Yongseok Koh
2019-01-10 18:22     ` Yongseok Koh
2019-01-10 18:35 ` [PATCH v3 " Yongseok Koh
2019-01-10 18:35   ` [PATCH v3 2/2] net/mlx5: fix instruction hotspot on replenishing Rx buffer Yongseok Koh
2019-01-10 19:10     ` Shahaf Shuler
2019-01-11  8:14   ` [PATCH v3 1/2] mbuf: add function returning default buffer address Andrew Rybchenko
2019-01-11 11:03     ` Yongseok Koh
2019-01-11 11:17       ` Andrew Rybchenko
2019-01-11 11:37         ` Yongseok Koh [this message]
2019-01-11 11:57         ` Bruce Richardson
2019-01-11 12:48           ` David Marchand
2019-01-14 15:51             ` Olivier Matz
2019-01-10 22:40 ` [PATCH v4 " Yongseok Koh
2019-01-10 22:40   ` [PATCH v4 2/2] net/mlx5: fix instruction hotspot on replenishing Rx buffer Yongseok Koh
2019-01-11  8:05   ` [PATCH v4 1/2] mbuf: add function returning default buffer address Olivier Matz
2019-01-11  8:11   ` David Marchand
2019-01-11  8:32     ` David Marchand
2019-01-11 11:09       ` Yongseok Koh
2019-01-11 10:25     ` Thomas Monjalon
2019-01-14 21:16 ` [PATCH v5 1/2] mbuf: add function returning " Yongseok Koh
2019-01-14 21:16   ` [PATCH v5 2/2] net/mlx5: fix instruction hotspot on replenishing Rx buffer Yongseok Koh
2019-02-06 15:54     ` Kevin Traynor
2019-02-21 19:10       ` Kevin Traynor
2019-03-08  2:05         ` Yongseok Koh
2019-01-15  1:35   ` [PATCH v5 1/2] mbuf: add function returning buffer address Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49ED7E73-6BB0-46DD-AE49-F39B54E18A30@mellanox.com \
    --to=yskoh@mellanox.com \
    --cc=arybchenko@solarflare.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.com \
    --cc=roszenrami@gmail.com \
    --cc=shahafs@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.