Re: [PATCH v3 1/3] ethdev: introduce pool sort capability

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

On 9/2/22 10:00, Hanumanth Pothula wrote:
> This patch adds support for the pool sort capability.

"Add support for serveral (?) mbuf pools per Rx queue."

I dislike the word "sort" in summary and the feature
description. IMHO it is too restrictive for intended behaviour.

The key feature here is just support for more than one mbuf
pool per Rx queue. That's it. Everything else should be out
of scope of the definiteion.

If buffers from many pools are provided, the hardware may do
whatever it wants with it. Use smaller buffers for small
packets and bigger for big. Use bigger buffers for small
packets if there is no small buffers available. Use big plus
small buffer if Rx scatter is enabled and a packet fits in
such combination. And so so on.

I.e. the feature should be orthogoal to Rx scatter.
Rx scatter just says if driver/application allows to chain
mbufs to receive a packet. If Rx scatter is disabled,
a packet must be delivered in a single mbuf (either big or
small). If Rx scatter is enable, a packet may be delivered
using a chain of mbufs obtained from provided pools (either
just one or many if several pools are supported).

Ideally the feature should be orthogonal to buffer split as
well. I.e. provide many pools for different segments.
May be it is an overkill to provide pools A and B for the first
segment and C and D for the second. It could be limitted to the
last segment only. If so, we need separate strcture (not
rte_eth_rxseg) to pass many pools. IMHO, an array of mempools
is sufficient - similar to Rx queue configuration.
I.e. no extra length since data length may be derived from
mempool element size.

> Some of the HW has support for choosing memory pools based on the
> packet's size. The pool sort capability allows PMD to choose a
> memory pool based on the packet's length.
> 
> This is often useful for saving the memory where the application
> can create a different pool to steer the specific size of the
> packet, thus enabling effective use of memory.
> 
> For example, let's say HW has a capability of three pools,
>   - pool-1 size is 2K
>   - pool-2 size is > 2K and < 4K
>   - pool-3 size is > 4K
> Here,
>          pool-1 can accommodate packets with sizes < 2K
>          pool-2 can accommodate packets with sizes > 2K and < 4K
>          pool-3 can accommodate packets with sizes > 4K
> 
> With pool sort capability enabled in SW, an application may create
> three pools of different sizes and send them to PMD. Allowing PMD
> to program HW based on packet lengths. So that packets with less
> than 2K are received on pool-1, packets with lengths between 2K
> and 4K are received on pool-2 and finally packets greater than 4K
> are received on pool-3.
> 
> The following two capabilities are added to the rte_eth_rxseg_capa
> structure,
> 1. pool_sort --> tells pool sort capability is supported by HW.
> 2. max_npool --> max number of pools supported by HW.
> 
> Defined new structure rte_eth_rxseg_sort, to be used only when pool
> sort capability is present. If required this may be extended further
> to support more configurations.
> 
> Signed-off-by: Hanumanth Pothula <hpothula@marvell.com>
> 
> v3:
>   - Implemented Pool Sort capability as new Rx offload capability,
>     RTE_ETH_RX_OFFLOAD_BUFFER_SORT.
> v2:
>   - Along with spec changes, uploading testpmd and driver changes.
> ---

[snip]