From: "Zhou, YidingX" <yidingx.zhou@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>,
"Burakov, Anatoly" <anatoly.burakov@intel.com>,
"He, Xingguang" <xingguang.he@intel.com>,
"stable@dpdk.org" <stable@dpdk.org>
Subject: RE: [PATCH v2] net/pcap: fix timeout of stopping device
Date: Tue, 6 Sep 2022 16:21:43 +0000 [thread overview]
Message-ID: <DM5PR1101MB210762AEC0B7C1FA47CD1AA7857E9@DM5PR1101MB2107.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20220906075737.2fb429a5@hermes.local>
On Tue, 6 Sep 2022 16:05:11 +0800
Yiding Zhou <yidingx.zhou@intel.com> wrote:
> The pcap file will be synchronized to the disk when stopping the device.
> It takes a long time if the file is large that would cause the 'detach
> sync request' timeout when the device is closed under multi-process
> scenario.
>
> This commit fixes the issue by using alarm handler to release dumper.
>
> Fixes: 0ecfb6c04d54 ("net/pcap: move handler to process private")
> Cc: stable@dpdk.org
>
> Signed-off-by: Yiding Zhou <yidingx.zhou@intel.com>
I think you need to redesign the handshake if this the case.
Forcing 30 second delay at the end of all uses of pcap is not acceptable.
Thanks for your comments.
According to my test, the time required to sync a 100G pcap file is about 20s,
so I set a delay of 30s. I also tried to use AIO, but some issue in the multi-process scenario.
And I also consider io_uring, it is only supported in linux-5.x, we need to consider compatibility,.
Maybe better way is to do more work to redesign the handshake.
next prev parent reply other threads:[~2022-09-06 16:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-25 7:20 [PATCH] net/pcap: reduce time for " Yiding Zhou
2022-08-25 10:09 ` Ferruh Yigit
2022-08-25 11:17 ` Zhou, YidingX
2022-08-25 12:21 ` Ferruh Yigit
2022-08-29 11:50 ` Zhou, YidingX
2022-08-31 16:42 ` Stephen Hemminger
2022-09-01 7:40 ` Zhou, YidingX
2022-09-06 8:05 ` [PATCH v2] net/pcap: fix timeout of " Yiding Zhou
2022-09-06 14:57 ` Stephen Hemminger
2022-09-06 16:21 ` Zhou, YidingX [this message]
2022-09-21 7:14 ` Zhou, YidingX
2022-10-03 15:00 ` Ferruh Yigit
2022-11-22 9:25 ` Zhou, YidingX
2022-11-22 17:28 ` Stephen Hemminger
2022-12-02 10:22 ` Zhou, YidingX
2022-11-29 14:11 ` Ferruh Yigit
2022-12-02 10:13 ` Zhou, YidingX
2022-12-02 11:19 ` Ferruh Yigit
2022-12-05 1:58 ` Zhou, YidingX
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=DM5PR1101MB210762AEC0B7C1FA47CD1AA7857E9@DM5PR1101MB2107.namprd11.prod.outlook.com \
--to=yidingx.zhou@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=qi.z.zhang@intel.com \
--cc=stable@dpdk.org \
--cc=stephen@networkplumber.org \
--cc=xingguang.he@intel.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 NNTP newsgroup(s).