From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AFD2CA0C43; Thu, 21 Oct 2021 22:28:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3BE8340040; Thu, 21 Oct 2021 22:28:54 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id 1DC354003F for ; Thu, 21 Oct 2021 22:28:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634848132; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Vwe6newBqgfYDfU1tZzKzqh7ZfafpntozaaSoylG9O8=; b=ZKDPK6pPIaPYmNevTW8S5Av6goS4IIqOy/Ds8U0YWRL9M/PynexSqUMPZ188RTQ59V9sjq Yc8JNRP744NyuF7xDn4XIhDHy453sKHLwmB73zUWnX2xjTO8qaDEYuydX9W+i1dlY4R7CZ Oo0kkmznkI3fp7MvL/8TMaHSw/yKzH0= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-577-vLny24U_N82exS_JrnDB9w-1; Thu, 21 Oct 2021 16:28:51 -0400 X-MC-Unique: vLny24U_N82exS_JrnDB9w-1 Received: by mail-lj1-f197.google.com with SMTP id 136-20020a2e098e000000b002110b902242so521386ljj.20 for ; Thu, 21 Oct 2021 13:28:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vwe6newBqgfYDfU1tZzKzqh7ZfafpntozaaSoylG9O8=; b=8KfKmj6THjOFalUX1nIHfgRP4XJtcvC12VQdYrOsP+R9LAMZBE+upT8oYdYOwunHLQ NLJLxzHBySat2QfYf2jPBj/B3RtABiOFAE0F1sXAdkQn9tnIL9OqvLJse3uM1TDQtFNf PCbJ279VlK/RRcloDbgjTQW4I7PsYlks1XQ/leTWiaa4LVDs1cJE95++sXOD9UP9PoJF SuNlsRH5lbARzYxNYkN5+nZcOElsTkhmg2Wld/vtajmlZHdnJAezfRS94gH+6sh4OuNb grjHVu8SO3hTD2Fbkitq++hHZlYx9/7cAc0TRlxPKkGnLxIm/r8ElzKVvGJeHtN88UpY oEzg== X-Gm-Message-State: AOAM531THpAjr0FBB82EMwMwa1Kk+S3eVLoNt6OgNXr+uxVpKC3hAL8K ALtYXic1NzULemKZQGlthNeppY4OcYqHDoQZzswAE3ZkMG0PUUvqSsQX6JOXlb5z77yiF/lX1tC MXA3yHHiUe5Ws7Ch0Q7s= X-Received: by 2002:a05:6512:31c3:: with SMTP id j3mr7388719lfe.217.1634848129761; Thu, 21 Oct 2021 13:28:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxntD2aS+GS5gspwVMxlcDSaIP1+qFCLwkbwfEccWP/wW9QXX0n0IdM5FSOww4Xy10kav7hkXFLTHPr2XkCLgw= X-Received: by 2002:a05:6512:31c3:: with SMTP id j3mr7388707lfe.217.1634848129555; Thu, 21 Oct 2021 13:28:49 -0700 (PDT) MIME-Version: 1.0 References: <20211021070355.3547582-1-andrew.rybchenko@oktetlabs.ru> In-Reply-To: <20211021070355.3547582-1-andrew.rybchenko@oktetlabs.ru> From: David Marchand Date: Thu, 21 Oct 2021 22:28:38 +0200 Message-ID: To: Andrew Rybchenko Cc: dev , Viacheslav Galaktionov , Andy Moreton Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] net/sfc: allow control threads for counter queue polling X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Thu, Oct 21, 2021 at 9:04 AM Andrew Rybchenko wrote: > > From: Viacheslav Galaktionov > > MAE counters can be polled from a control thread if no service core is > allocated for this. > > Signed-off-by: Viacheslav Galaktionov > Signed-off-by: Andrew Rybchenko > Reviewed-by: Andy Moreton > --- > The problem to require service cores for HW offload was raised by > David on review in 21.08 release cycle. Thanks for following up! > > doc/guides/rel_notes/release_21_11.rst | 1 + > drivers/net/sfc/sfc_mae.h | 26 +++++- > drivers/net/sfc/sfc_mae_counter.c | 120 ++++++++++++++++++++----- > 3 files changed, 123 insertions(+), 24 deletions(-) > > diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst > index 041383ee2a..9517e0fb0a 100644 > --- a/doc/guides/rel_notes/release_21_11.rst > +++ b/doc/guides/rel_notes/release_21_11.rst > @@ -158,6 +158,7 @@ New Features > > * Added port representors support on SN1000 SmartNICs > * Added flow API transfer proxy support > + * Added support for flow counters without service cores > > * **Updated Marvell cnxk crypto PMD.** > > diff --git a/drivers/net/sfc/sfc_mae.h b/drivers/net/sfc/sfc_mae.h > index 23dcf1e482..45a2fdc3bb 100644 > --- a/drivers/net/sfc/sfc_mae.h > +++ b/drivers/net/sfc/sfc_mae.h > @@ -127,6 +127,13 @@ struct sfc_mae_counters { > unsigned int n_mae_counters; > }; > > +/** Options for MAE counter polling mode */ > +enum sfc_mae_counter_polling_mode { > + SFC_MAE_COUNTER_POLLING_OFF = 0, > + SFC_MAE_COUNTER_POLLING_SERVICE, > + SFC_MAE_COUNTER_POLLING_THREAD, > +}; > + > struct sfc_mae_counter_registry { > /* Common counter information */ > /** Counters collection */ > @@ -143,10 +150,21 @@ struct sfc_mae_counter_registry { > bool use_credits; > > /* Information used by configuration routines */ > - /** Counter service core ID */ > - uint32_t service_core_id; > - /** Counter service ID */ > - uint32_t service_id; > + enum sfc_mae_counter_polling_mode polling_mode; > + union { > + struct { > + /** Counter service core ID */ > + uint32_t core_id; > + /** Counter service ID */ > + uint32_t id; > + } service; > + struct { > + /** Counter thread ID */ > + pthread_t id; > + /** The thread should keep running */ > + volatile bool run; volatile is probably unneeded. > + } thread; > + } polling; > }; > > /** > diff --git a/drivers/net/sfc/sfc_mae_counter.c b/drivers/net/sfc/sfc_mae_counter.c > index 418caffe59..5f2aea1bf4 100644 > --- a/drivers/net/sfc/sfc_mae_counter.c > +++ b/drivers/net/sfc/sfc_mae_counter.c > @@ -45,9 +45,6 @@ sfc_mae_counter_rxq_required(struct sfc_adapter *sa) > if (encp->enc_mae_supported == B_FALSE) > return false; > > - if (sfc_mae_counter_get_service_lcore(sa) == RTE_MAX_LCORE) > - return false; > - > return true; > } > > @@ -402,6 +399,23 @@ sfc_mae_counter_routine(void *arg) > return 0; > } > > +static void * > +sfc_mae_counter_thread(void *data) > +{ > + struct sfc_adapter *sa = data; > + struct sfc_mae_counter_registry *counter_registry = > + &sa->mae.counter_registry; > + > + /* > + * Check run condition without atomic since it is not a problem > + * if we run a bit more before we notice stop request > + */ I find it clearer when we have clear pairs of atomic acquire load/release store (maybe because I feel like I understand something :-)). So it may not be a problem, but is there a reason to avoid this (acquire) atomic load? Otherwise, patch lgtm. Thanks. -- David Marchand