13/02/2023 18:04, Ophir Munk:
> Since the new rte API was "discussed in recent years" and it is also
> dependent on different driver vendors acceptance - I suggest that the
> compilation option will be applied now.
I think there is a misunderstanding here.
> The new rte API effort will start in
..@arm.com; jer...@marvell.com; rm...@marvell.com;
> dsinghra...@marvell.com
> Subject: Re: [PATCH v1] config: make max memzones definition configurable
>
> On Mon, Feb 13, 2023 at 02:55:41PM +0100, Thomas Monjalon wrote:
> > 13/02/2023 12:05, Bruce Richardson:
> > > On Sun, F
On Mon, Feb 13, 2023 at 02:55:41PM +0100, Thomas Monjalon wrote:
> 13/02/2023 12:05, Bruce Richardson:
> > On Sun, Feb 12, 2023 at 10:53:19AM +0200, Ophir Munk wrote:
> > > In current DPDK the RTE_MAX_MEMZONE definition is unconditionally
> > > hard coded as 2560. For applications requiring differ
13/02/2023 12:05, Bruce Richardson:
> On Sun, Feb 12, 2023 at 10:53:19AM +0200, 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 its value
On Sun, Feb 12, 2023 at 10:53:19AM +0200, 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 its value as part of the meson
> command line rather
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 its value as part of the meson
command line rather than changing the dpdk source code per application.
An example would
6 matches
Mail list logo
