[dpdk-dev] Huge pages to be allocated based on number of mbufs

[dpdk-dev] Huge pages to be allocated based on number of mbufs

[Saurabh Mishra]

Hi,

We are planning to support virtio, vmxnet3, ixgbe, i40e, bxn2x and SR-IOV
on some of them with DPDK.

We have seen that even if we give correct number of mbufs given the number
hugepages reserved, rte_eth_tx_queue_setup() may still fail with no enough
memory (I saw this on i40evf but worked on virtio and vmxnet3).

We like to know what's the recommended way to determine how many hugepages
we should allocate given the number of mbufs such that queue setup APIs
also don't fail.

Since we will be running on low-end systems too we need to be careful about
reserving hugepages.

Thanks,
/Saurabh

Re: [dpdk-dev] Huge pages to be allocated based on number of mbufs

[Zoltan Kiss]

On 14/03/16 17:54, Saurabh Mishra wrote:
> Hi,
>
> We are planning to support virtio, vmxnet3, ixgbe, i40e, bxn2x and SR-IOV
> on some of them with DPDK.
>
> We have seen that even if we give correct number of mbufs given the number
> hugepages reserved, rte_eth_tx_queue_setup() may still fail with no enough
> memory (I saw this on i40evf but worked on virtio and vmxnet3).
>
> We like to know what's the recommended way to determine how many hugepages
> we should allocate given the number of mbufs such that queue setup APIs
> also don't fail.

I think you ran into a fragmentation problem. If you allocate the 
hugepages later on after startup, chances are they are fragmented in the 
memory. When you allocate a pool, DPDK needs a continuous area of memory 
on the hugepages.
You should allocate them through the kernel boot params so they'll be as 
continuous as possible.


>
> Since we will be running on low-end systems too we need to be careful about
> reserving hugepages.
>
> Thanks,
> /Saurabh
>