Thank you Morten Brorup and Thomas Monjalon for the fruitful discussion.
I am sending a V2 version that meets the understandings in the RFC so far.
If confirmed I will send PATCH V1.
Thank you, Tyler Retzlaff, for your comments.
> > --- a/app/test/test_memzone.c
> > +++ b/app/test/test_memzone.c
> > @@ -871,7 +871,7 @@ test_memzone_bounded(void) static int
> > test_memzone_free(void)
> > {
> > - const struct rte_memzone *mz[RTE_MAX_MEMZONE + 1];
> > + const struct rte_m
Thank you Stephen Memminger for you comment.
> Subject: Re: [RFC] lib: set/get max memzone segments
>
> On Wed, 19 Apr 2023 11:36:34 +0300
> Ophir Munk wrote:
>
> > +int ecore_mz_mapping_alloc(void)
> > +{
> > + ecore_mz_mappi
Thank you Devendra Singh Rawat for your valuable comments.
> >+int ecore_mz_mapping_alloc(void)
> >+{
> >+ecore_mz_mapping = rte_malloc("ecore_mz_map", 0,
> >+rte_memzone_max_get() * sizeof(struct rte_memzone *));
>
> Second parameter of rte_malloc() should be size and Third param
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, 21 April 2023 16.57
>
> 21/04/2023 13:08, Morten Brørup:
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > Sent: Friday, 21 April 2023 10.35
> > > 20/04/2023 20:20, Tyler Retzlaff:
> > > > On Thu, Apr 20, 2023 at 09:
21/04/2023 13:08, Morten Brørup:
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Friday, 21 April 2023 10.35
> > 20/04/2023 20:20, Tyler Retzlaff:
> > > On Thu, Apr 20, 2023 at 09:43:28AM +0200, Thomas Monjalon wrote:
> > > > 19/04/2023 16:51, Tyler Retzlaff:
> > > > > On Wed, Apr
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, 21 April 2023 10.35
>
> 20/04/2023 20:20, Tyler Retzlaff:
> > On Thu, Apr 20, 2023 at 09:43:28AM +0200, Thomas Monjalon wrote:
> > > 19/04/2023 16:51, Tyler Retzlaff:
> > > > On Wed, Apr 19, 2023 at 11:36:34AM +0300, Ophir Munk w
20/04/2023 20:20, Tyler Retzlaff:
> On Thu, Apr 20, 2023 at 09:43:28AM +0200, Thomas Monjalon wrote:
> > 19/04/2023 16:51, Tyler Retzlaff:
> > > On Wed, Apr 19, 2023 at 11:36:34AM +0300, Ophir Munk wrote:
> > > > In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard
> > > > coded a
On Thu, Apr 20, 2023 at 09:43:28AM +0200, Thomas Monjalon wrote:
> 19/04/2023 16:51, Tyler Retzlaff:
> > On Wed, Apr 19, 2023 at 11:36:34AM +0300, Ophir Munk wrote:
> > > In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard
> > > coded as 2560. For applications requiring differen
19/04/2023 16:51, Tyler Retzlaff:
> On Wed, Apr 19, 2023 at 11:36:34AM +0300, 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 val
Devendra Singh Rawat, Alok Prasad - can you please give your feedback on the
qede driver updates?
> -Original Message-
> 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 co
On Wed, Apr 19, 2023 at 11:36:34AM +0300, 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
On Wed, 19 Apr 2023 11:36:34 +0300
Ophir Munk wrote:
> +int ecore_mz_mapping_alloc(void)
> +{
> + ecore_mz_mapping = rte_malloc("ecore_mz_map", 0,
> + rte_memzone_max_get() * sizeof(struct rte_memzone *));
Why not use rte_calloc(), and devices should be using NUMA aware
allocatio
>diff --git a/drivers/net/qede/base/bcm_osal.c
>b/drivers/net/qede/base/bcm_osal.c
>index 2c59397..f195f2c 100644
>--- a/drivers/net/qede/base/bcm_osal.c
>+++ b/drivers/net/qede/base/bcm_osal.c
>@@ -47,10 +47,26 @@ void osal_poll_mode_dpc(osal_int_ptr_t
>hwfn_cookie) }
>
> /* Array of memzone poi
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
15 matches
Mail list logo
