[PATCH] app/pdump: enforcing pdump to use sw mempool

[PATCH] app/pdump: enforcing pdump to use sw mempool

[Harman Kalra]

Since pdump uses SW rings to manage packets hence
pdump should use SW ring mempool for managing its
own copy of packets.

Signed-off-by: Harman Kalra <hkalra@marvell.com>
---
 app/pdump/main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/app/pdump/main.c b/app/pdump/main.c
index ccf2a1d2f..d0e342645 100644
--- a/app/pdump/main.c
+++ b/app/pdump/main.c
@@ -598,11 +598,12 @@ create_mp_ring_vdev(void)
 		mbuf_pool = rte_mempool_lookup(mempool_name);
 		if (mbuf_pool == NULL) {
 			/* create mempool */
-			mbuf_pool = rte_pktmbuf_pool_create(mempool_name,
+			mbuf_pool = rte_pktmbuf_pool_create_by_ops(mempool_name,
 					pt->total_num_mbufs,
 					MBUF_POOL_CACHE_SIZE, 0,
 					pt->mbuf_data_size,
-					rte_socket_id());
+					rte_socket_id(),
+					RTE_MBUF_DEFAULT_MEMPOOL_OPS);
 			if (mbuf_pool == NULL) {
 				cleanup_rings();
 				rte_exit(EXIT_FAILURE,
-- 
2.18.0

Re: [dpdk-dev] [PATCH] app/pdump: enforcing pdump to use sw mempool

[Thomas Monjalon]

15/03/2019 16:27, Harman Kalra:
> Since pdump uses SW rings to manage packets hence
> pdump should use SW ring mempool for managing its
> own copy of packets.

I'm not sure to understand the reasoning.
Reshma, Olivier, Andrew, any opinion?

Let's take a decision for this very old patch.

Re: [dpdk-dev] [PATCH] app/pdump: enforcing pdump to use sw mempool

[Olivier Matz]

Hi,

On Thu, Jul 04, 2019 at 06:29:25PM +0200, Thomas Monjalon wrote:
> 15/03/2019 16:27, Harman Kalra:
> > Since pdump uses SW rings to manage packets hence
> > pdump should use SW ring mempool for managing its
> > own copy of packets.
> 
> I'm not sure to understand the reasoning.
> Reshma, Olivier, Andrew, any opinion?
> 
> Let's take a decision for this very old patch.

From what I understand, many mempools of packets are created, to
store the copy of dumped packets. I suppose that it may not be
possible to create as many mempools by using the "best" mbuf pool
(from rte_mbuf_best_mempool_ops()).

Using a "ring_mp_mc" as mempool ops should always be possible.
I think it would be safer to use "ring_mp_mc" instead of
CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS, because the latter could be
overriden on a specific platform.

Olivier

Re: [dpdk-dev] [EXT] Re: [PATCH] app/pdump: enforcing pdump to use sw mempool

[Harman Kalra]

On Fri, Jul 05, 2019 at 03:48:01PM +0200, Olivier Matz wrote:
> External Email
> 
> ----------------------------------------------------------------------
> Hi,
> 
> On Thu, Jul 04, 2019 at 06:29:25PM +0200, Thomas Monjalon wrote:
> > 15/03/2019 16:27, Harman Kalra:
> > > Since pdump uses SW rings to manage packets hence
> > > pdump should use SW ring mempool for managing its
> > > own copy of packets.
> > 
> > I'm not sure to understand the reasoning.
> > Reshma, Olivier, Andrew, any opinion?
> > 
> > Let's take a decision for this very old patch.
> 
> From what I understand, many mempools of packets are created, to
> store the copy of dumped packets. I suppose that it may not be
> possible to create as many mempools by using the "best" mbuf pool
> (from rte_mbuf_best_mempool_ops()).
> 
> Using a "ring_mp_mc" as mempool ops should always be possible.
> I think it would be safer to use "ring_mp_mc" instead of
> CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS, because the latter could be
> overriden on a specific platform.
> 
> Olivier

Following are some reasons for this patch:
1. As we all know dpdk-pdump app creates a mempool for receiving packets (from primary process) into the mbufs, which would get tx'ed into pcap device and freed. Using hw mempool for creating mempool for dpdk-pdump mbufs was generating segmentation fault because hw mempool vfio is setup by primary process and secondary will not have access to its bar regions.

2. Setting up a seperate hw mempool vfio device for secondary generates following error:
"cannot find TAILQ entry for PCI device!"
http://git.dpdk.org/dpdk/tree/drivers/bus/pci/linux/pci_vfio.c#n823
which means secondary cannot setup a new device which is not set by primary.

3. Since pdump creates mempool for its own local mbufs, we could not feel the requirement for hw mempool, as SW mempool in our opinion is capable enough for working in all conditions.

Re: [dpdk-dev] [EXT] Re: [PATCH] app/pdump: enforcing pdump to use sw mempool

[Thomas Monjalon]

05/07/2019 16:39, Harman Kalra:
> On Fri, Jul 05, 2019 at 03:48:01PM +0200, Olivier Matz wrote:
> > On Thu, Jul 04, 2019 at 06:29:25PM +0200, Thomas Monjalon wrote:
> > > 15/03/2019 16:27, Harman Kalra:
> > > > Since pdump uses SW rings to manage packets hence
> > > > pdump should use SW ring mempool for managing its
> > > > own copy of packets.
> > > 
> > > I'm not sure to understand the reasoning.
> > > Reshma, Olivier, Andrew, any opinion?
> > > 
> > > Let's take a decision for this very old patch.
> > 
> > From what I understand, many mempools of packets are created, to
> > store the copy of dumped packets. I suppose that it may not be
> > possible to create as many mempools by using the "best" mbuf pool
> > (from rte_mbuf_best_mempool_ops()).
> > 
> > Using a "ring_mp_mc" as mempool ops should always be possible.
> > I think it would be safer to use "ring_mp_mc" instead of
> > CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS, because the latter could be
> > overriden on a specific platform.
> > 
> > Olivier
> 
> Following are some reasons for this patch:
> 1. As we all know dpdk-pdump app creates a mempool for receiving packets (from primary process) into the mbufs, which would get tx'ed into pcap device and freed. Using hw mempool for creating mempool for dpdk-pdump mbufs was generating segmentation fault because hw mempool vfio is setup by primary process and secondary will not have access to its bar regions.
> 
> 2. Setting up a seperate hw mempool vfio device for secondary generates following error:
> "cannot find TAILQ entry for PCI device!"
> http://git.dpdk.org/dpdk/tree/drivers/bus/pci/linux/pci_vfio.c#n823
> which means secondary cannot setup a new device which is not set by primary.
> 
> 3. Since pdump creates mempool for its own local mbufs, we could not feel the requirement for hw mempool, as SW mempool in our opinion is capable enough for working in all conditions.

OK
From the commit log, it is just missing to explain
that HW mempool cannot be used in secondary if initialized in primary,
and cannot be initialized in secondary process.
Then it will become clear :)

Please, do you want to reword a v2?

[dpdk-dev] [PATCH v2] app/pdump: enforcing pdump to use sw mempool

[Harman Kalra]

A secondary process cannot access HW mempool already
initiazed by primary, and neither it can setup its own
HW mempool due to its own restrictions.

Since dpdk-pdump creates mempool for managing its local
mbufs, SW mempool is capable enough to solve this purpose.

Signed-off-by: Harman Kalra <hkalra@marvell.com>
---
 app/pdump/main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/app/pdump/main.c b/app/pdump/main.c
index 80dc924cf..c739ae43d 100644
--- a/app/pdump/main.c
+++ b/app/pdump/main.c
@@ -604,11 +604,12 @@ create_mp_ring_vdev(void)
 		mbuf_pool = rte_mempool_lookup(mempool_name);
 		if (mbuf_pool == NULL) {
 			/* create mempool */
-			mbuf_pool = rte_pktmbuf_pool_create(mempool_name,
+			mbuf_pool = rte_pktmbuf_pool_create_by_ops(mempool_name,
 					pt->total_num_mbufs,
 					MBUF_POOL_CACHE_SIZE, 0,
 					pt->mbuf_data_size,
-					rte_socket_id());
+					rte_socket_id(),
+					RTE_MBUF_DEFAULT_MEMPOOL_OPS);
 			if (mbuf_pool == NULL) {
 				cleanup_rings();
 				rte_exit(EXIT_FAILURE,
-- 
2.18.0

Re: [dpdk-dev] [PATCH v2] app/pdump: enforcing pdump to use sw mempool

[Olivier Matz]

hi,

On Fri, Jul 05, 2019 at 03:40:20PM +0000, Harman Kalra wrote:
> A secondary process cannot access HW mempool already
> initiazed by primary, and neither it can setup its own
> HW mempool due to its own restrictions.
> 
> Since dpdk-pdump creates mempool for managing its local
> mbufs, SW mempool is capable enough to solve this purpose.
> 
> Signed-off-by: Harman Kalra <hkalra@marvell.com>
> ---
>  app/pdump/main.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/app/pdump/main.c b/app/pdump/main.c
> index 80dc924cf..c739ae43d 100644
> --- a/app/pdump/main.c
> +++ b/app/pdump/main.c
> @@ -604,11 +604,12 @@ create_mp_ring_vdev(void)
>  		mbuf_pool = rte_mempool_lookup(mempool_name);
>  		if (mbuf_pool == NULL) {
>  			/* create mempool */
> -			mbuf_pool = rte_pktmbuf_pool_create(mempool_name,
> +			mbuf_pool = rte_pktmbuf_pool_create_by_ops(mempool_name,
>  					pt->total_num_mbufs,
>  					MBUF_POOL_CACHE_SIZE, 0,
>  					pt->mbuf_data_size,
> -					rte_socket_id());
> +					rte_socket_id(),
> +					RTE_MBUF_DEFAULT_MEMPOOL_OPS);
>  			if (mbuf_pool == NULL) {
>  				cleanup_rings();
>  				rte_exit(EXIT_FAILURE,
> -- 
> 2.18.0
> 

Did you see the comment in my previous mail?

"""
I think it would be safer to use "ring_mp_mc" instead of
CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS, because the latter could be
overriden on a specific platform.
"""

Thanks,
Olivier

[dpdk-dev] [PATCH v3] app/pdump: enforcing pdump to use sw mempool

[Harman Kalra]

A secondary process cannot access HW mempool already
initiazed by primary, and neither it can setup its own
HW mempool due to its own restrictions.

Since dpdk-pdump creates mempool for managing its local
mbufs, SW mempool is capable enough to solve this purpose.

Signed-off-by: Harman Kalra <hkalra@marvell.com>
---
 app/pdump/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/pdump/main.c b/app/pdump/main.c
index 80dc924cf..cd0986aee 100644
--- a/app/pdump/main.c
+++ b/app/pdump/main.c
@@ -604,11 +604,11 @@ create_mp_ring_vdev(void)
 		mbuf_pool = rte_mempool_lookup(mempool_name);
 		if (mbuf_pool == NULL) {
 			/* create mempool */
-			mbuf_pool = rte_pktmbuf_pool_create(mempool_name,
+			mbuf_pool = rte_pktmbuf_pool_create_by_ops(mempool_name,
 					pt->total_num_mbufs,
 					MBUF_POOL_CACHE_SIZE, 0,
 					pt->mbuf_data_size,
-					rte_socket_id());
+					rte_socket_id(), "ring_mp_mc");
 			if (mbuf_pool == NULL) {
 				cleanup_rings();
 				rte_exit(EXIT_FAILURE,
-- 
2.18.0

[dpdk-dev] [PATCH v4] app/pdump: enforcing pdump to use SW mempool

[Harman Kalra]

A secondary process cannot access HW mempool already
initiazed by primary, and neither it can setup its own
HW mempool due to its own restrictions.

Since dpdk-pdump creates mempool for managing its local
mbufs, SW mempool is capable enough to solve this purpose.

Signed-off-by: Harman Kalra <hkalra@marvell.com>
---
 app/pdump/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/pdump/main.c b/app/pdump/main.c
index 80dc924cf..cd0986aee 100644
--- a/app/pdump/main.c
+++ b/app/pdump/main.c
@@ -604,11 +604,11 @@ create_mp_ring_vdev(void)
 		mbuf_pool = rte_mempool_lookup(mempool_name);
 		if (mbuf_pool == NULL) {
 			/* create mempool */
-			mbuf_pool = rte_pktmbuf_pool_create(mempool_name,
+			mbuf_pool = rte_pktmbuf_pool_create_by_ops(mempool_name,
 					pt->total_num_mbufs,
 					MBUF_POOL_CACHE_SIZE, 0,
 					pt->mbuf_data_size,
-					rte_socket_id());
+					rte_socket_id(), "ring_mp_mc");
 			if (mbuf_pool == NULL) {
 				cleanup_rings();
 				rte_exit(EXIT_FAILURE,
-- 
2.18.0

Re: [dpdk-dev] [PATCH v4] app/pdump: enforcing pdump to use SW mempool

[Thomas Monjalon]

10/07/2019 11:22, Harman Kalra:
> A secondary process cannot access HW mempool already
> initiazed by primary, and neither it can setup its own
> HW mempool due to its own restrictions.
> 
> Since dpdk-pdump creates mempool for managing its local
> mbufs, SW mempool is capable enough to solve this purpose.
> 
> Signed-off-by: Harman Kalra <hkalra@marvell.com>

Applied, thanks