Hi Morten,
>
> I retracted my objection to the RFC, but should also have added:
>
> Acked-by: Morten Brørup
Ack.
Hi Anatoly,
Thank you for your review. I noticed a review by David Marchand that addresses
similar points to yours. In V4 I supply a reply to you both.
>
> Commit message could use a little rewording and shortening. Suggested:
>
> ---
>
> Currently, RTE_MAX_MEMZONE constant is used to decide h
ruce Richardson ; Devendra
> Singh Rawat ; Alok Prasad ;
> Ophir Munk ; Matan Azrad ;
> NBU-Contact-Thomas Monjalon (EXTERNAL) ; Lior
> Margalit
> Subject: Re: [PATCH V3] lib: set/get max memzone segments
>
> Hello Ophir,
>
> Good thing someone is looking into
Hi,
On 5/3/2023 8:26 AM, Ophir Munk wrote:
In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard
coded as 2560. For applications requiring different values of this
parameter – it is more convenient to set the max value via an rte API -
rather than changing the dpdk source code
Hello Ophir,
Good thing someone is looking into this.
Thanks.
I have a few comments.
This commitlog is a bit compact.
Separating it with some empty lines would help digest it.
On Wed, May 3, 2023 at 9:27 AM Ophir Munk wrote:
>
> In current DPDK the RTE_MAX_MEMZONE definition is unconditional
> From: Ophir Munk [mailto:ophi...@nvidia.com]
> Sent: Wednesday, 3 May 2023 09.27
>
> In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard
> coded as 2560. For applications requiring different values of this
> parameter – it is more convenient to set the max value via an rte AP
In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard
coded as 2560. For applications requiring different values of this
parameter – it is more convenient to set the max value via an rte API -
rather than changing the dpdk source code per application. In many
organizations, the p
7 matches
Mail list logo