From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 604BCA09F6; Thu, 17 Dec 2020 16:08:20 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C2643CA24; Thu, 17 Dec 2020 16:08:18 +0100 (CET) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by dpdk.org (Postfix) with ESMTP id 8DD40CA1E for ; Thu, 17 Dec 2020 16:08:17 +0100 (CET) Received: by mail-wm1-f51.google.com with SMTP id c133so5836673wme.4 for ; Thu, 17 Dec 2020 07:08:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=4/rP0g/3jdvu4zESjalOrXaPpwqrlh0jAr0Voz9lNUg=; b=abMnOWRD/G5AIAUC6JXriuEDHGqjOizlysJHXh4txdZ8pOSAuDNMYyTzfthodlw9GT 3DnIv5Pi4iFGImxAdswXatvsVnneHlOYH4FSvHhH1MOyp2NnRFWqL00BrikPVB7FwcbG WtvQ3gNtNnaNb5h3lH/t6MLxbRmdtZfneimq5FT4mw3PlwQH+ORqofkaQ0HfSPqtQbVi zrL1XXryJY8BwUzXzBcokMrfSMDAwOFohqntYtG5dFuoH0M6xLwEW5q0lA1+MdT8t2po EezHvEZWMQe5YLFRnNGHUdrSOF+sxEYKOu41gLRNt49om4Ofr1Svr9K4EkFhLg6z1YRC ZvCw== X-Gm-Message-State: AOAM532dne1Kg0f9xoD7F5b/TVOt30EnHSUPHFslygcMce/DRuakZMOO qc/LijVixt08zZpkF1N7f/I= X-Google-Smtp-Source: ABdhPJwJ5nXaDq+jDDs0yjiPmUXQB1g/VFuInrri6HA6Fbtwx0fMeSD0/RCBlHsZs4bUxRB+yx1ihw== X-Received: by 2002:a1c:2785:: with SMTP id n127mr9146694wmn.148.1608217696176; Thu, 17 Dec 2020 07:08:16 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id v7sm8641128wma.26.2020.12.17.07.08.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Dec 2020 07:08:15 -0800 (PST) Message-ID: From: Luca Boccassi To: Long Li , Stephen Hemminger Cc: dev@dpdk.org, Stephen Hemminger , Long Li Date: Thu, 17 Dec 2020 15:08:14 +0000 In-Reply-To: <1606809383-26660-1-git-send-email-longli@linuxonhyperv.com> References: <1606809383-26660-1-git-send-email-longli@linuxonhyperv.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.2 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/2] eal/hotplug: allow monitor to be setup by multiple places X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, 2020-11-30 at 23:56 -0800, Long Li wrote: > From: Stephen Hemminger >=20 > In some cases, a device or infrastructure may want to enable hotplug > but application may also try and start hotplug as well. Therefore > change the monitor_started from a boolean into a reference count. >=20 > Signed-off-by: Stephen Hemminger > Signed-off-by: Long Li > --- > lib/librte_eal/linux/eal_dev.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) >=20 > diff --git a/lib/librte_eal/linux/eal_dev.c b/lib/librte_eal/linux/eal_de= v.c > index 5c0e752b2d..5fa679989e 100644 > --- a/lib/librte_eal/linux/eal_dev.c > +++ b/lib/librte_eal/linux/eal_dev.c > @@ -23,8 +23,11 @@ > =20 > #include "eal_private.h" > =20 > -static struct rte_intr_handle intr_handle =3D {.fd =3D -1 }; > -static bool monitor_started; > +static struct rte_intr_handle intr_handle =3D { > + .type =3D RTE_INTR_HANDLE_DEV_EVENT, > + .fd =3D -1, > +}; > +static uint32_t monitor_refcount; > static bool hotplug_handle; > =20 > #define EAL_UEV_MSG_LEN 4096 > @@ -300,7 +303,7 @@ rte_dev_event_monitor_start(void) > { > int ret; > =20 > - if (monitor_started) > + if (__atomic_fetch_add(&monitor_refcount, 1, __ATOMIC_RELAXED)) > return 0; If dev_uev_socket_fd_create or rte_intr_callback_register fail, you'll have incremented the refcount but there won't be anything registered, and calls to rte_dev_event_monitor_start will do nothing. Will that be a problem? In other words, it seems to me the semantics is changing from call rte_dev_event_monitor_start until it succeeds, to call rte_dev_event_monitor_start, and if it fails call rte_dev_event_monitor_stop and then rte_dev_event_monitor_start again > ret =3D dev_uev_socket_fd_create(); > @@ -309,7 +312,6 @@ rte_dev_event_monitor_start(void) > return -1; > } > =20 > - intr_handle.type =3D RTE_INTR_HANDLE_DEV_EVENT; > ret =3D rte_intr_callback_register(&intr_handle, dev_uev_handler, NULL)= ; > =20 > if (ret) { > @@ -317,8 +319,6 @@ rte_dev_event_monitor_start(void) > return -1; > } > =20 > - monitor_started =3D true; > - > return 0; > } > =20 > @@ -327,7 +327,7 @@ rte_dev_event_monitor_stop(void) > { > int ret; > =20 > - if (!monitor_started) > + if (__atomic_sub_fetch(&monitor_refcount, 1, __ATOMIC_RELAXED)) > return 0; Same question in reverse - if rte_intr_callback_unregister fails, the refcount will have been decreased anyway, so nothing will close the file handle, right? > ret =3D rte_intr_callback_unregister(&intr_handle, dev_uev_handler, > @@ -339,7 +339,6 @@ rte_dev_event_monitor_stop(void) > =20 > close(intr_handle.fd); > intr_handle.fd =3D -1; > - monitor_started =3D false; > =20 > return 0; > }