In l3fwd no of transmit queues is calculated based on no of lcores with which it is launched. Hence maximum no of tx queues possible per port should depend on RTE_MAX_LCORE value. Fixes: 268888b5b020 ("examples/l3fwd: modularize") Cc: stable@dpdk.org Signed-off-by: Harman Kalra <hkalra@marvell.com> --- examples/l3fwd/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c index d62dec434..bb49e5faf 100644 --- a/examples/l3fwd/main.c +++ b/examples/l3fwd/main.c @@ -48,7 +48,7 @@ #include "l3fwd.h" #include "l3fwd_event.h" -#define MAX_TX_QUEUE_PER_PORT RTE_MAX_ETHPORTS +#define MAX_TX_QUEUE_PER_PORT RTE_MAX_LCORE #define MAX_RX_QUEUE_PER_PORT 128 #define MAX_LCORE_PARAMS 1024 -- 2.18.0
Ping...
On Tue, Dec 15, 2020 at 12:32:55AM +0530, Harman Kalra wrote:
> In l3fwd no of transmit queues is calculated based on no of
> lcores with which it is launched. Hence maximum no of tx
> queues possible per port should depend on RTE_MAX_LCORE value.
>
> Fixes: 268888b5b020 ("examples/l3fwd: modularize")
> Cc: stable@dpdk.org
>
> Signed-off-by: Harman Kalra <hkalra@marvell.com>
> ---
> examples/l3fwd/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
> index d62dec434..bb49e5faf 100644
> --- a/examples/l3fwd/main.c
> +++ b/examples/l3fwd/main.c
> @@ -48,7 +48,7 @@
> #include "l3fwd.h"
> #include "l3fwd_event.h"
>
> -#define MAX_TX_QUEUE_PER_PORT RTE_MAX_ETHPORTS
> +#define MAX_TX_QUEUE_PER_PORT RTE_MAX_LCORE
> #define MAX_RX_QUEUE_PER_PORT 128
>
> #define MAX_LCORE_PARAMS 1024
> --
> 2.18.0
>
On Mon, Dec 14, 2020 at 8:03 PM Harman Kalra <hkalra@marvell.com> wrote: > > In l3fwd no of transmit queues is calculated based on no of > lcores with which it is launched. Hence maximum no of tx > queues possible per port should depend on RTE_MAX_LCORE value. For the title, we are not "fixing" the Tx queue count. WDYT of: examples/l3fwd: remove limitation on Tx queue count > > Fixes: 268888b5b020 ("examples/l3fwd: modularize") This commit simply moves code around, so it is unlikely to be the origin. Afaiu, this behavior has been present since the start. I'd rather flag Fixes: af75078fece3 ("first public release") > Cc: stable@dpdk.org > > Signed-off-by: Harman Kalra <hkalra@marvell.com> > --- > examples/l3fwd/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c > index d62dec434..bb49e5faf 100644 > --- a/examples/l3fwd/main.c > +++ b/examples/l3fwd/main.c > @@ -48,7 +48,7 @@ > #include "l3fwd.h" > #include "l3fwd_event.h" > > -#define MAX_TX_QUEUE_PER_PORT RTE_MAX_ETHPORTS > +#define MAX_TX_QUEUE_PER_PORT RTE_MAX_LCORE > #define MAX_RX_QUEUE_PER_PORT 128 > > #define MAX_LCORE_PARAMS 1024 Later in the code, the associated check on nb_lcores > RTE_MAX_LCORE does not make much sense. But keeping this MAX_TX_QUEUE_PER_PORT macro is a way to document how the txq are allocated. So this change lgtm. Reviewed-by: David Marchand <david.marchand@redhat.com> -- David Marchand
On Tue, Jan 12, 2021 at 09:58:06AM +0100, David Marchand wrote: > External Email > > ---------------------------------------------------------------------- > On Mon, Dec 14, 2020 at 8:03 PM Harman Kalra <hkalra@marvell.com> wrote: > > > > In l3fwd no of transmit queues is calculated based on no of > > lcores with which it is launched. Hence maximum no of tx > > queues possible per port should depend on RTE_MAX_LCORE value. > > For the title, we are not "fixing" the Tx queue count. > WDYT of: > examples/l3fwd: remove limitation on Tx queue count Hi David Thanks for reviewing, I will push V2 with the required changes. > > > > > Fixes: 268888b5b020 ("examples/l3fwd: modularize") > > This commit simply moves code around, so it is unlikely to be the origin. > Afaiu, this behavior has been present since the start. > I'd rather flag > > Fixes: af75078fece3 ("first public release") > > > Cc: stable@dpdk.org > > > > Signed-off-by: Harman Kalra <hkalra@marvell.com> > > --- > > examples/l3fwd/main.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c > > index d62dec434..bb49e5faf 100644 > > --- a/examples/l3fwd/main.c > > +++ b/examples/l3fwd/main.c > > @@ -48,7 +48,7 @@ > > #include "l3fwd.h" > > #include "l3fwd_event.h" > > > > -#define MAX_TX_QUEUE_PER_PORT RTE_MAX_ETHPORTS > > +#define MAX_TX_QUEUE_PER_PORT RTE_MAX_LCORE > > #define MAX_RX_QUEUE_PER_PORT 128 > > > > #define MAX_LCORE_PARAMS 1024 > > Later in the code, the associated check on nb_lcores > RTE_MAX_LCORE > does not make much sense. > But keeping this MAX_TX_QUEUE_PER_PORT macro is a way to document how > the txq are allocated. > So this change lgtm. > > Reviewed-by: David Marchand <david.marchand@redhat.com> > > > -- > David Marchand >
In l3fwd no of transmit queues is calculated based on no of lcores with which it is launched. Hence maximum no of tx queues possible per port should depend on RTE_MAX_LCORE value. Fixes: af75078fece3 ("first public release") Cc: stable@dpdk.org Signed-off-by: Harman Kalra <hkalra@marvell.com> Reviewed-by: David Marchand <david.marchand@redhat.com> --- V2: * Reworded patch subject * Corrected the Fixes tag commit examples/l3fwd/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c index d62dec434..bb49e5faf 100644 --- a/examples/l3fwd/main.c +++ b/examples/l3fwd/main.c @@ -48,7 +48,7 @@ #include "l3fwd.h" #include "l3fwd_event.h" -#define MAX_TX_QUEUE_PER_PORT RTE_MAX_ETHPORTS +#define MAX_TX_QUEUE_PER_PORT RTE_MAX_LCORE #define MAX_RX_QUEUE_PER_PORT 128 #define MAX_LCORE_PARAMS 1024 -- 2.18.0
On Tue, Jan 12, 2021 at 7:25 PM Harman Kalra <hkalra@marvell.com> wrote:
>
> In l3fwd no of transmit queues is calculated based on no of
> lcores with which it is launched. Hence maximum no of tx
> queues possible per port should depend on RTE_MAX_LCORE value.
>
> Fixes: af75078fece3 ("first public release")
> Cc: stable@dpdk.org
>
> Signed-off-by: Harman Kalra <hkalra@marvell.com>
> Reviewed-by: David Marchand <david.marchand@redhat.com>
Applied, thanks.
--
David Marchand