DPDK usage discussions
 help / color / mirror / Atom feed
* Getting mbuf pointer from buf_addr pointer
@ 2022-07-11  9:21 Antonio Di Bacco
  2022-07-12  8:32 ` Dmitry Kozlyuk
  0 siblings, 1 reply; 4+ messages in thread
From: Antonio Di Bacco @ 2022-07-11  9:21 UTC (permalink / raw)
  To: users

Is there any API that allows me to get the MBUF pointer given its
buf_addr pointer?

Regards,
Antonio.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Getting mbuf pointer from buf_addr pointer
  2022-07-11  9:21 Getting mbuf pointer from buf_addr pointer Antonio Di Bacco
@ 2022-07-12  8:32 ` Dmitry Kozlyuk
  2022-07-12 10:30   ` Antonio Di Bacco
  0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Kozlyuk @ 2022-07-12  8:32 UTC (permalink / raw)
  To: Antonio Di Bacco; +Cc: users

2022-07-11 11:21 (UTC+0200), Antonio Di Bacco:
> Is there any API that allows me to get the MBUF pointer given its
> buf_addr pointer?

No.

How did you come across this need?
Sounds like an app design flaw.
What is the original problem you're solving?

P.S. It may be possible in specific cases when you know (from code)
how mempool sets buf_addr for a given mbuf,
and that PMDs don't change buf_addr with the used set of offloads.
Apparently, this approach would be extremely brittle and dangerous.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Getting mbuf pointer from buf_addr pointer
  2022-07-12  8:32 ` Dmitry Kozlyuk
@ 2022-07-12 10:30   ` Antonio Di Bacco
  2022-07-12 11:22     ` Dmitry Kozlyuk
  0 siblings, 1 reply; 4+ messages in thread
From: Antonio Di Bacco @ 2022-07-12 10:30 UTC (permalink / raw)
  To: Dmitry Kozlyuk; +Cc: users

I was asked to reproduce the exact same behaviour of a library that
used VMDQ queues without DPDK.
Now this library offered an API to allocate a buffer for a packet and
returned an address where the application could write its data.

void* vmdqNew (vmdqUidPOOLt* p);

I implemented the same API to allocate an MBUF from a pool and I also
return the right address as a void* but then to transmit the packet I
need the address of the MBUF for the tx_burst API and I don't have it.

On Tue, Jul 12, 2022 at 10:32 AM Dmitry Kozlyuk
<dmitry.kozliuk@gmail.com> wrote:
>
> 2022-07-11 11:21 (UTC+0200), Antonio Di Bacco:
> > Is there any API that allows me to get the MBUF pointer given its
> > buf_addr pointer?
>
> No.
>
> How did you come across this need?
> Sounds like an app design flaw.
> What is the original problem you're solving?
>
> P.S. It may be possible in specific cases when you know (from code)
> how mempool sets buf_addr for a given mbuf,
> and that PMDs don't change buf_addr with the used set of offloads.
> Apparently, this approach would be extremely brittle and dangerous.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Getting mbuf pointer from buf_addr pointer
  2022-07-12 10:30   ` Antonio Di Bacco
@ 2022-07-12 11:22     ` Dmitry Kozlyuk
  0 siblings, 0 replies; 4+ messages in thread
From: Dmitry Kozlyuk @ 2022-07-12 11:22 UTC (permalink / raw)
  To: Antonio Di Bacco; +Cc: users

2022-07-12 12:30 (UTC+0200), Antonio Di Bacco:
> I was asked to reproduce the exact same behaviour of a library that
> used VMDQ queues without DPDK.
> Now this library offered an API to allocate a buffer for a packet and
> returned an address where the application could write its data.
> 
> void* vmdqNew (vmdqUidPOOLt* p);
> 
> I implemented the same API to allocate an MBUF from a pool and I also
> return the right address as a void* but then to transmit the packet I
> need the address of the MBUF for the tx_burst API and I don't have it.

Since you create mbufs and send them, the approach I mentioned is viable.
See rte_mbuf_buf_addr() and do the reverse to calculate the pointer to mbuf.
There is no API because it cannot work for any mbuf, but you case is limited
(there are chained mbufs, externally-attached mbufs, etc).
BTW, in general you could save a back-reference to the mbuf
just before the buffer you return from vmdqNew(), in pktmbuf private data.
But direct calculation is more efficient.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-07-12 11:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-11  9:21 Getting mbuf pointer from buf_addr pointer Antonio Di Bacco
2022-07-12  8:32 ` Dmitry Kozlyuk
2022-07-12 10:30   ` Antonio Di Bacco
2022-07-12 11:22     ` Dmitry Kozlyuk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).