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 BB65845A82 for ; Wed, 2 Oct 2024 21:18:52 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8EBB3402A7; Wed, 2 Oct 2024 21:18:52 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 2A3E1402A7 for ; Wed, 2 Oct 2024 21:18:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1727896730; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I33yt/Cdiq04EHWZLclVc0pVVJckx8eZ7Ca3QWZr4Os=; b=FuZ0rTXf37IVpSxzGBDybqQgO78jx44WRza+pbC8JIivVIxt9fI47TTh7J3SEZ8+l79MFH 8zMudI+rVHztC1Hs4XXEU1Pdlgj+M7IKUAql8Pd2p7rzqgS0lPQomkaWg116BA8o7LSVDN KkMyrPBfzaDDex/Vj5uqsgAap8Oj+Kg= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-ubmZxh62PkC54-cn67UwDQ-1; Wed, 02 Oct 2024 15:18:48 -0400 X-MC-Unique: ubmZxh62PkC54-cn67UwDQ-1 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-5389ef4c213so57300e87.3 for ; Wed, 02 Oct 2024 12:18:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727896727; x=1728501527; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=I33yt/Cdiq04EHWZLclVc0pVVJckx8eZ7Ca3QWZr4Os=; b=WIwH+Uk15691WPISc9PM2wXpEuoOwJW704bQ8lNNl/J8Regrxpk5rdVbjucrv8CD7T zoAuWQxYWlVNLRS10BUcex49UcRZAly0ITwd8F3S2JJKuK2sfUXYfQH4LxJ2XhekKMOp jaZbb8pc1L3JVxXYhAaRMaVsvuSDs2qCaL8Oh3/LCyz0c2l3ckeIZ/c7XXA/4OcavU9d GwBGMoW+NgZsxxXVWtLXOhDrZ0WJFZX6/C/44pcqN63zPxiCXHQcXE4C7Y05cfiRSGO7 V6zoJhhRWqXv3uk8cx2n+EW4ywhUIcKnTKksLGJzZlUurMIhzRnfVxPBGCUc29pZD7TM 0Vbw== X-Forwarded-Encrypted: i=1; AJvYcCXHnNX6KfUpva8WCY5BlICczr0eofbXoaS7Zlo63jtitel0HzaCWs7EDvS7It4bV5wSZbQJOyU=@dpdk.org X-Gm-Message-State: AOJu0YwBvfCj9Grd+9K5A3MZg5Jak2BDadzqydvgODg7WmBk3J7yJQSp ticGPIzA+DglP1w1tDSZda5w+62RWWyB6Pz2d/mhOwAOTnrWM6pYu9jjI8JsVZDUVilrU9YtDRE uKfxv52X+OpG9e2cYDNeo1PI0JOqTG8DXrnQhzZ7j/NmevFzuqg92vqfK/CSVxqDnl7+NoNJdQm /I4HcRK7HXLDxEtBpVXnA= X-Received: by 2002:a05:6512:3994:b0:533:44e7:1b2a with SMTP id 2adb3069b0e04-539a0793eedmr2902881e87.40.1727896727183; Wed, 02 Oct 2024 12:18:47 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHXKhcgt7G+ZPUXm2RYgNQizbGGJ24nT8OL4MdVCt3fYDeQFEgmMpcGnmkK658ce32YaZUBzCdGxvBZgsXv9+U= X-Received: by 2002:a05:6512:3994:b0:533:44e7:1b2a with SMTP id 2adb3069b0e04-539a0793eedmr2902861e87.40.1727896726753; Wed, 02 Oct 2024 12:18:46 -0700 (PDT) MIME-Version: 1.0 References: <20241002155709.2522273-1-david.marchand@redhat.com> <20241002155709.2522273-3-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Wed, 2 Oct 2024 21:18:35 +0200 Message-ID: Subject: Re: [PATCH 2/2] ethdev: fix race on ports for telemetry commands To: Robin Jarry Cc: Bruce Richardson , dev@dpdk.org, ktraynor@redhat.com, stable@dpdk.org, Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Keith Wiles , Ciara Power X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Wed, Oct 2, 2024 at 9:09=E2=80=AFPM Robin Jarry wrot= e: > >> An alternative to this macro-fu, is to just define a single ethdev > >> telemetry function, and within that, take the lock and then dispatch t= o the > >> appropriate subfunction based upon the actual command coming in. The > >> dispatch may be slightly slower due to the additional text matching (o= nly > >> from byte 8 onwards, so very short strings), but I think the code coul= d be > >> a simpler in C rather than in macros, and the perf impact for telemetr= y is > >> likely to be negligible, compared to the overhead of the socket I/O et= c. > > > > Hopefully, dispatching performance is not important here. > > I was going to suggest adding a rte_spinlock_t* parameter to a new > telemetry register function that would need to be held while the > callback is invoked. Or if we want to keep doors open to other kinds of > lock, a wrapper callback. Well, as you had experimented this approach, we know this does not work: the ethdev lock is in dpdk shared memory which is not available yet at the time RTE_INIT() is called. A single callback is strange, I guess you mean pre/post callbacks then. --=20 David Marchand