Re: [dpdk-dev] [PATCH] app/testpmd: fix vdev socket initialization

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 10/12/2018 10:34 AM, phil.yang@arm.com wrote:
> The cmdline settings of port-numa-config and rxring-numa-config have been
> flushed by the following init_config. If we don't configure the
> port-numa-config, the virtual device will allocate the device ports to
> socket 0. It will cause failure when the socket 0 is unavailable.
> 
> eg:
> testpmd -l <cores from socket 1> --vdev net_pcap0,iface=lo
> --socket-mem=64 -- --numa --port-numa-config="(0,1)"
> --ring-numa-config="(0,1,1),(0,2,1)" -i
> 
> ...
> Configuring Port 0 (socket 0)
> Failed to setup RX queue:No mempool allocation on the socket 0
> EAL: Error - exiting with code: 1
>   Cause: Start ports failed
> 
> Fix by allocate the devices port to the first available socket or the
> socket configured in port-numa-config.

I confirm this fixes the issue, by making vdev to allocate from available socket
instead of hardcoded socket 0, overall this make sense.

But currently there is no way to request mempool form "socket 0" if only cores
from "socket 1" provided in "-l", even with "port-numa-config" and
"rxring-numa-config".
Both this behavior and the problem this patch fixes caused by patch:
Commit dbfb8ec7094c ("app/testpmd: optimize mbuf pool allocation")

It is good to have optimized mempool allocation but I think this shouldn't limit
the tool. If user wants mempools from specific socket, let it have.

What about changing the default behavior to:
1- Allocate mempool only from socket that coremask provided (current approach)
2- Plus, allocate mempool from sockets of attached devices (this is alternative
solution to this patch, your solution seems better for virtual devices but for
physical devices allocating from socket it connects can be better)
3- Plus, allocate mempool from sockets provided in "port-numa-config" and
"rxring-numa-config"

What do you think?


> 
> Fixes: 487f9a5 ("app/testpmd: fix NUMA structures initialization")
> 
> Signed-off-by: Phil Yang <phil.yang@arm.com>
> Reviewed-by: Gavin Hu <Gavin.Hu@arm.com>

<...>