* [dpdk-users] manually construct mbuf
@ 2017-03-16 3:28 Mike Shang
2017-03-16 3:41 ` Wiles, Keith
0 siblings, 1 reply; 3+ messages in thread
From: Mike Shang @ 2017-03-16 3:28 UTC (permalink / raw)
To: users
Is it possible to construct mbuf manually instead getting one from
mempool ? I've got a situation that needs to handle a relatively small
number of jumbo frames, we keep a mempool of objects of regular size and
wanted to construct mbuf ourselves for jumbo frames as one segment using
rte_malloc. I have searched the dpdk source code a bit but can't find such
use case. Is it doable with dpdk ? Or it's recommended to keep a separate
mempool for objects of larger size ?
Thanks,
Mike
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-users] manually construct mbuf
2017-03-16 3:28 [dpdk-users] manually construct mbuf Mike Shang
@ 2017-03-16 3:41 ` Wiles, Keith
2017-03-16 16:09 ` Stephen Hemminger
0 siblings, 1 reply; 3+ messages in thread
From: Wiles, Keith @ 2017-03-16 3:41 UTC (permalink / raw)
To: Mike Shang; +Cc: users
> On Mar 16, 2017, at 11:28 AM, Mike Shang <mshang5@gmail.com> wrote:
>
> Is it possible to construct mbuf manually instead getting one from
> mempool ? I've got a situation that needs to handle a relatively small
> number of jumbo frames, we keep a mempool of objects of regular size and
> wanted to construct mbuf ourselves for jumbo frames as one segment using
> rte_malloc. I have searched the dpdk source code a bit but can't find such
> use case. Is it doable with dpdk ? Or it's recommended to keep a separate
> mempool for objects of larger size ?
You could try to construct your own mbuf, but when the system attempts to free the mbuf you would need to build a lot more then just the mbuf as the mempool pointer is hiding in the data/mbuf and it expects to point to a valid mempool.
What I would do is just allocate a couple jumbo mbuf in a new mempool allocation and use those mbufs when you want to send jumbo frames. Trying to create a special mbuf is not going to super simple, just create a new mempool with N number of mbufs.
>
> Thanks,
> Mike
Regards,
Keith
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-users] manually construct mbuf
2017-03-16 3:41 ` Wiles, Keith
@ 2017-03-16 16:09 ` Stephen Hemminger
0 siblings, 0 replies; 3+ messages in thread
From: Stephen Hemminger @ 2017-03-16 16:09 UTC (permalink / raw)
To: Wiles, Keith; +Cc: Mike Shang, users
On Thu, 16 Mar 2017 03:41:14 +0000
"Wiles, Keith" <keith.wiles@intel.com> wrote:
> > On Mar 16, 2017, at 11:28 AM, Mike Shang <mshang5@gmail.com> wrote:
> >
> > Is it possible to construct mbuf manually instead getting one from
> > mempool ? I've got a situation that needs to handle a relatively small
> > number of jumbo frames, we keep a mempool of objects of regular size and
> > wanted to construct mbuf ourselves for jumbo frames as one segment using
> > rte_malloc. I have searched the dpdk source code a bit but can't find such
> > use case. Is it doable with dpdk ? Or it's recommended to keep a separate
> > mempool for objects of larger size ?
>
> You could try to construct your own mbuf, but when the system attempts to free the mbuf you would need to build a lot more then just the mbuf as the mempool pointer is hiding in the data/mbuf and it expects to point to a valid mempool.
>
> What I would do is just allocate a couple jumbo mbuf in a new mempool allocation and use those mbufs when you want to send jumbo frames. Trying to create a special mbuf is not going to super simple, just create a new mempool with N number of mbufs.
Or teach your code how to use chained multi-segment mbuf's. That is the right way to handle larger data
without having to pin down large chunks of memory.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-03-16 16:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-16 3:28 [dpdk-users] manually construct mbuf Mike Shang
2017-03-16 3:41 ` Wiles, Keith
2017-03-16 16:09 ` Stephen Hemminger
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).