From: Harman Kalra <hkalra@marvell.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
"reshma.pattan@intel.com" <reshma.pattan@intel.com>,
"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Jerin Jacob Kollanukkaran" <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] app/pdump: enforcing pdump to use sw mempool
Date: Fri, 5 Jul 2019 14:39:03 +0000 [thread overview]
Message-ID: <20190705143847.GA182782@outlook.office365.com> (raw)
In-Reply-To: <20190705134801.qirbqvafroci3oxv@platinum>
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.
next prev parent reply other threads:[~2019-07-05 14:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 15:27 [dpdk-dev] " Harman Kalra
2019-03-15 15:27 ` Harman Kalra
2019-07-04 16:29 ` Thomas Monjalon
2019-07-05 13:48 ` Olivier Matz
2019-07-05 14:39 ` Harman Kalra [this message]
2019-07-05 15:09 ` [dpdk-dev] [EXT] " Thomas Monjalon
2019-07-05 15:40 ` [dpdk-dev] [PATCH v2] " Harman Kalra
2019-07-05 15:50 ` Olivier Matz
2019-07-09 8:44 ` [dpdk-dev] [PATCH v3] " Harman Kalra
2019-07-10 9:22 ` [dpdk-dev] [PATCH v4] app/pdump: enforcing pdump to use SW mempool Harman Kalra
2019-07-10 22:21 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190705143847.GA182782@outlook.office365.com \
--to=hkalra@marvell.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=olivier.matz@6wind.com \
--cc=reshma.pattan@intel.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).