On 9/21/2022 8:14 AM, Zhou, YidingX wrote:
-----Original Message-----
From: Stephen Hemminger <step...@networkplumber.org>
Sent: Tuesday, September 6, 2022 10:58 PM
To: Zhou, YidingX <yidingx.z...@intel.com>
Cc: dev@dpdk.org; Zhang, Qi Z <qi.z.zh...@intel.com>; Burakov, Anatoly
<anatoly.bura...@intel.com>; He, Xingguang <xingguang...@intel.com>;
sta...@dpdk.org
Subject: Re: [PATCH v2] net/pcap: fix timeout of stopping device
On Tue, 6 Sep 2022 16:05:11 +0800
Yiding Zhou <yidingx.z...@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: sta...@dpdk.org
Signed-off-by: Yiding Zhou <yidingx.z...@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.
@Zhang, Qi Z Do we need to redesign the handshake to fix this?
Hi Yiding,
Your approach works, but Stephen's comment is to not add this delay by
default, because this delay is not always required.
Can you please provide more details on multi-process communication and
call trace, to help us think about a solution to address this issue in a
more generic way (not just for pcap but for any case device close takes
more than multi-process timeout)?
