From: Stephen Hemminger <stephen@networkplumber.org>
To: Fuji Nafiul <nafiul.fuji@gmail.com>, dev@dpdk.org
Subject: Re: High packet capturing rate in DPDK enabled port
Date: Mon, 6 May 2024 10:59:59 -0700 [thread overview]
Message-ID: <20240506105959.4bce7265@hermes.local> (raw)
In-Reply-To: <CA+3hWeyG3tKv1+8gv0D3SzV_9oObwx5LFhp8_3xfCB4CGuU9GA@mail.gmail.com>
On Mon, 6 May 2024 02:15:10 +0600
Fuji Nafiul <nafiul.fuji@gmail.com> wrote:
> I understand that I will need more cores and SSD, which I have. The thing
> is is there any current project available that exposes params to dump the
> highest possible rate with available resources? or I have to use the pdump
> framework and implement it myself. I previously wrote dumping code
> integrated with my dpdk media which was able to dump around 0.5 Gbits/s (1
> big rte ring and 2 cores, not much optimized) then found out that pdump
> framework does a similar kind of thing but just with a secondary process
> with interception in rx/tx. But I need to modify to scale it, That is why I
> was wondering whether there is already a project that aims to dump the
> highest rate possible in dpdk port, otherwise, I will start modifying it. I
> haven't looked into "dpdkcap" code but it says that it aims to dump around
> 10Gbit/s if resources are available. Has anyone used or tested this project
> or tried to modify pdump code to scale?
The things that could speed up dpdk-dumpcap are:
1. Use Linux async io via ioring. But creates work around supporting
older distros. I would not make it an option, if ioring works it should
be used. Might be easier not that RHEL/CentOS 7 is end of life and does
not need to be supported.
2. Get rid of copy in pdump side by using ref counts. But this exposes
potential issues with drivers and applications that don't handle
mbufs with refcount > 1. It means if refcount > 1 then the application
can not overwrite the buffer. On Tx side, that means handling vlan
gets more complicated. On Rx side, it needs to be an option; and most
applications (especially 3rd party) can't handle refcounts.
3. Get rid of callback and just put mbuf into ring directly.
Indirect calls slow things down and introduces bugs when secondary
is doing rx/tx.
4. Have dumpcap use multithreads (one per queue) when doing ring -> write.
These are in order of complexity/performance gain.
I haven't done them because don't work full time on this. And it would
require lots of testing effort as wel.
prev parent reply other threads:[~2024-05-06 18:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-05 7:09 High packet capturing rate in DPDK enabled port Fuji Nafiul
2024-05-05 16:02 ` Stephen Hemminger
[not found] ` <CA+3hWeyG3tKv1+8gv0D3SzV_9oObwx5LFhp8_3xfCB4CGuU9GA@mail.gmail.com>
2024-05-06 17:59 ` Stephen Hemminger [this message]
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=20240506105959.4bce7265@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=nafiul.fuji@gmail.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).