From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 9D970A034E
	for <public@inbox.dpdk.org>; Fri, 21 Jan 2022 17:20:02 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 30D6240040;
	Fri, 21 Jan 2022 17:20:02 +0100 (CET)
Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com
 [209.85.214.173])
 by mails.dpdk.org (Postfix) with ESMTP id 901C94276F
 for <stable@dpdk.org>; Fri, 21 Jan 2022 17:20:00 +0100 (CET)
Received: by mail-pl1-f173.google.com with SMTP id n11so8912798plf.4
 for <stable@dpdk.org>; Fri, 21 Jan 2022 08:20:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
 h=date:from:to:cc:subject:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=V+IHdBFiOT21bHkLZTl+mv6olaiAoXC30XmgmGw0+K4=;
 b=3HHkFEp+it9lyGiXm8yOnX3S+9myFSXX7vfEpBQXByvdbjD+qsHf629244DPBhCcnI
 KewN7mUnRJjeGro54fTJyHbJsyI5SHd7etFI5dmu90IS+PpzPrMV/FhdNo+2XKVazMot
 A2xfTP+yZ61ky/68R5STvWXCbepujfWwxWtb1W0TsNdh1fVNhBOhk79CIbAOpJ9LHPqD
 UIk/AAX1k8JWSWqncyKkf5eLX/boyQfNEa/5hwdjKdiaVHM/oTjohHDVvxYxMcfyU+td
 jNQbvnK4Mmlp2xNK+8qRmQd8uAIFKw3TofT3ZSBN1veU20LsFNYq9sWu/lEqcRJzhYhL
 xhmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=V+IHdBFiOT21bHkLZTl+mv6olaiAoXC30XmgmGw0+K4=;
 b=VYuhSDDzHxApAht2ygNKX/zDcxzokzTtLnmzxifSL2SvDFVlBBuHYAxOwvHTK52COR
 j5ebqaTjYUFjJq1wSSmgmDIa+oK3xLry6UcJ1W3edY8QTFq/FCI8UhnbD6BxDd548ufM
 /Q4bGmJiscPz9zRG11BCVed5fuyA0ACidJrbixH+EtogZ04x+P89Fdj4g6KIw0KhZt+c
 6/37hEXQJ2IRWeu6VS6Tb5rI9B0705z4kYPeFGvvwUrSeesLGPEFeZGvSj68uOIOymiT
 4vR9PiOTMJtmcLuplBhvRaaE/THkVTUc56GbgU9CDgotMbFlNWBuamvdy5LCNuggQfDw
 WqYg==
X-Gm-Message-State: AOAM533GEkXjnHw3qKzUFvv8vx+oIvvxQ3+Tb6v0ElHt27CXC8CbRmlk
 bOGuI1cdVpGgPpnxdzfP0mtNVQ==
X-Google-Smtp-Source: ABdhPJwizKga//aQWbJSbKOV+q/uyHNYZ1DfIeOXNHRnCTpByGbJXryYAcMpJqWJfZTG7bKlyBFlBg==
X-Received: by 2002:a17:90b:391:: with SMTP id
 ga17mr1523716pjb.78.1642781999650; 
 Fri, 21 Jan 2022 08:19:59 -0800 (PST)
Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199])
 by smtp.gmail.com with ESMTPSA id
 q25sm6873406pfh.167.2022.01.21.08.19.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 21 Jan 2022 08:19:59 -0800 (PST)
Date: Fri, 21 Jan 2022 08:19:56 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: Wei Huang <wei.huang@intel.com>
Cc: dev@dpdk.org, rosen.xu@intel.com, qi.z.zhang@intel.com, stable@dpdk.org,
 tianfei.zhang@intel.com, ferruh.yigit@intel.com, david.marchand@redhat.com
Subject: Re: [PATCH v5] raw/ifpga: fix pthread cannot join
Message-ID: <20220121081956.4837e66a@hermes.local>
In-Reply-To: <20220121033246.10339-1-wei.huang@intel.com>
References: <20220121012932.9827-1-wei.huang>
 <20220121033246.10339-1-wei.huang@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
 <mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
 <mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org

On Thu, 20 Jan 2022 22:32:46 -0500
Wei Huang <wei.huang@intel.com> wrote:

> @@ -497,7 +497,7 @@ static int set_surprise_link_check_aer(
>  	int gsd_enable, ret;
>  #define MS 1000
>  
> -	while (1) {
> +	while (rte_atomic32_read(&ifpga_monitor_start)) {

Better, but rte_atomic is deprecated in favor of using __atomic builtin
instead. This is because there are more options possible with 
__atomic_load_n than rte_atomic32_read.  rte_atomic32_read has to assume
worst case memory ordering, and your example relaxed memory ordering is
what you need.