Hi Andrew,
On Sat, Jun 9, 2018 at 2:23 AM, Andrew Rybchenko
wrote:
> BTW, thinking about function I found out there is a trap in private area
> size related to the function. I think that the function description should
> highlight that rte_pktmbuf_priv_size(m->pool) should be used to
> find out
Hi Dan,
On 06/09/2018 03:24 AM, Dan Gora wrote:
+{
+if (md->priv_size == 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
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 fi
> On Jun 8, 2018, at 2:06 AM, Andrew Rybchenko
> wrote:
>
> On 06/08/2018 02:54 AM, Dan Gora wrote:
>> Add an inline accessor function to return the starting address of
>> the private data area in the supplied mbuf.
>>
>> If the user did not allocate space for a private data area in the
>> mb
On 06/08/2018 02:54 AM, Dan Gora wrote:
Add an inline accessor function to return the starting address of
the private data area in the supplied mbuf.
If the user did not allocate space for a private data area in the
mbuf's memory pool, then return NULL.
This allows applications to easily access
On 08-Jun-18 12:54 AM, Dan Gora wrote:
Add an inline accessor function to return the starting address of
the private data area in the supplied mbuf.
If the user did not allocate space for a private data area in the
mbuf's memory pool, then return NULL.
This allows applications to easily access
6 matches
Mail list logo
