[dpdk-dev] ISSUE IN rte_bitmap

[dpdk-dev] ISSUE IN rte_bitmap

[Ariel Rodriguez]

Hi , i am facing a issue regarding with the maximum amount of bits that the
rte_bitmap allows.

Example :

bmp_mem_size = rte_bitmap_get_memory_footprint(40000000);

OK

(bmp_mem_size==2101312 (size in bytes aligned). Around 2MB)

but if i do this:

bmp_mem_size = rte_bitmap_get_memory_footprint(4294967292); (MAX uint32_t).

(bmp_mem_size == 64).

obviously this is wrong , besides the validation problem inside the
function rte_bitmap_get_memory_footprint, the main problem is that the
rte_bitmap api uses word size (4 bytes ints) for calculations of the max
bitmap size and ,of course, make them turn around.

In the rte_sched code there is a similar issue. In theory (By doc) the qos
scheduler can handle a configuration like this:

struct rte_sched_port_hierarchy {
uint32_t queue:2;    /**< Queue ID (0 .. 3) */
uint32_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
uint32_t pipe:20; /**< Pipe ID */  (Compile time configuration) 1M
subscribers
uint32_t subport:6; /**< Subport ID */ 32 subport
uint32_t color:2; /**< Color */
};


If one try to make a struct rte_sched_port* with that configuration (4095
MAX pipe profiles) , the api fails because when the function
rte_sched_port_config() tries to initialize the maximum memory use for that
configuration previously calling rte_sched_port_get_array_base() , that
function generates invalid total size, because the total memory size needed
is beyond 4Gb , bigger than unsigned int max limit. (Again here the code is
using uint32_t data for size calculation).

I know maybe the case use of qos scheduler is not intend for that huge
configuration but looking at the code there is no limitation except for the
4 bytes RSS struct rte_sched_port_hierarchy bit fields .

[dpdk-dev] ISSUE IN rte_bitmap

[Ariel Rodriguez]

Hi , i am facing a issue regarding with the maximum amount of bits that the
rte_bitmap allows.

Example :

bmp_mem_size = rte_bitmap_get_memory_footprint(40000000);

OK

(bmp_mem_size==2101312 (size in bytes aligned). Around 2MB)

but if i do this:

bmp_mem_size = rte_bitmap_get_memory_footprint(4294967292); (MAX uint32_t).

(bmp_mem_size == 64).

obviously this is wrong , besides the validation problem inside the
function rte_bitmap_get_memory_footprint, the main problem is that the
rte_bitmap api uses word size (4 bytes ints) for calculations of the max
bitmap size and ,of course, make them turn around.

In the rte_sched code there is a similar issue. In theory (By doc) the qos
scheduler can handle a configuration like this:

struct rte_sched_port_hierarchy {
uint32_t queue:2;    /**< Queue ID (0 .. 3) */
uint32_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
uint32_t pipe:20; /**< Pipe ID */  (Compile time configuration) 1M
subscribers
uint32_t subport:6; /**< Subport ID */ 32 subport
uint32_t color:2; /**< Color */
};


If one try to make a struct rte_sched_port* with that configuration (4095
MAX pipe profiles) , the api fails because when the function
rte_sched_port_config() tries to initialize the maximum memory use for that
configuration previously calling rte_sched_port_get_array_base() , that
function generates invalid total size, because the total memory size needed
is beyond 4Gb , bigger than unsigned int max limit. (Again here the code is
using uint32_t data for size calculation).

I know maybe the case use of qos scheduler is not intend for that huge
configuration but looking at the code there is no limitation except for the
4 bytes RSS struct rte_sched_port_hierarchy bit fields .

[dpdk-dev] ISSUE IN rte_bitmap

[Ariel Rodriguez]

Hi , i am facing a issue regarding with the maximum amount of bits that the
rte_bitmap allows.

Example :

bmp_mem_size = rte_bitmap_get_memory_footprint(40000000);

OK

(bmp_mem_size==2101312 (size in bytes aligned). Around 2MB)

but if i do this:

bmp_mem_size = rte_bitmap_get_memory_footprint(4294967292); (MAX uint32_t).

(bmp_mem_size == 64).

obviously this is wrong , besides the validation problem inside the
function rte_bitmap_get_memory_footprint, the main problem is that the
rte_bitmap api uses word size (4 bytes ints) for calculations of the max
bitmap size and ,of course, make them turn around.

In the rte_sched code there is a similar issue. In theory (By doc) the qos
scheduler can handle a configuration like this:

struct rte_sched_port_hierarchy {
uint32_t queue:2;    /**< Queue ID (0 .. 3) */
uint32_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
uint32_t pipe:20; /**< Pipe ID */  (Compile time configuration) 1M
subscribers
uint32_t subport:6; /**< Subport ID */ 32 subport
uint32_t color:2; /**< Color */
};


If one try to make a struct rte_sched_port* with that configuration (4095
MAX pipe profiles) , the api fails because when the function
rte_sched_port_config() tries to initialize the maximum memory use for that
configuration previously calling rte_sched_port_get_array_base() , that
function generates invalid total size, because the total memory size needed
is beyond 4Gb , bigger than unsigned int max limit. (Again here the code is
using uint32_t data for size calculation).

I know maybe the case use of qos scheduler is not intend for that huge
configuration but looking at the code there is no limitation except for the
4 bytes RSS struct rte_sched_port_hierarchy bit fields .