From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8ADAAC47DD9 for ; Mon, 26 Feb 2024 01:18:48 +0000 (UTC) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6E276402B2; Mon, 26 Feb 2024 02:18:47 +0100 (CET) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by mails.dpdk.org (Postfix) with ESMTP id A4BDA40271 for ; Mon, 26 Feb 2024 02:18:45 +0100 (CET) Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-6e4f3cbb518so237932b3a.3 for ; Sun, 25 Feb 2024 17:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1708910324; x=1709515124; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=V7YfbGzDDdDNpdf3Jtid5E4ZRwpGaD78hs2kp3r+U+s=; b=DjnkWagDR/Xdgz/Jxqo6Cv/qMFnr2pt9j/4f4bKedQbv9yUXVo2jxDn8U0BP9sMAZb OByCpS30d1QvAhMdYsij6kOM0U1+gfeAFgv9TjowaURmsfFW0qLgBx9VS5BEgTlOj1Q6 teCyyPNAR917pj0ufCVjLJddpT0ExSOn4lsI61gATzjO2ua1vJhgtvqCNTEqpBR6OeXV xlomNKZvtl1AjYGEp8BnR5+Op3pTC6xb2jrwpJF++nJfwemUZcIN3xh41Anm+e4HwGa/ 41EsJqDRO+2z9QMVMAeocL+8FZ1XZyYJ3Y/u0uxMWwrOMsiTGbTiVob4FEXZyjs5IUEs YzbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708910324; x=1709515124; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V7YfbGzDDdDNpdf3Jtid5E4ZRwpGaD78hs2kp3r+U+s=; b=anBs9CHuEW1AW93nBDzvezUuXYh6xXk11W1RJcmKBWfmADxn2yntJ+OeDUd0c1ixTG 6k4OK0n22UQbnLz8HNhYgSXZdJEC4Ksh9kzQkakDOjUfcTqNIJU+oIPVYzvCxTzGfLAY OXGjkLaLQ3P2bYVRVPloLGD4xJd8OKF753fBPcuKVdWC0Lygfqp7p11tI+OhNpSDz/06 lPhY6YaKnnVhGLDNhuqzLOEzMPsg6uCpo5cDtJsTThbQDtJ36F4DSXIY0KO7PSYNlOCS NGVx01m6OaKpnCvJvJgF3w4U58sABSD3ivS9fk5SZes5DV7vSvG0mk5tquI6sbTFKE0B pfWg== X-Gm-Message-State: AOJu0YxLqfY6kEhW8MfE/9N65IpkIPnErunHKlDXObwRthm6kb0EkaNv 3EpCSKybEakFlmppu/Tt16LQrL0nTrpFfBCXO0zVw/24T8uv2mQwzee3f7Dw5FA= X-Google-Smtp-Source: AGHT+IH+ZbzbHwm+21p94J2WA5Lnortf/8g0ehw6i16Ol82BWWYRBmLmXGMCnXOTLPHiFTKJIRZR/Q== X-Received: by 2002:a05:6a21:1518:b0:1a0:96cd:39f3 with SMTP id nq24-20020a056a21151800b001a096cd39f3mr5076222pzb.0.1708910324648; Sun, 25 Feb 2024 17:18:44 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id st15-20020a17090b1fcf00b00296f4fc7e60sm5112583pjb.12.2024.02.25.17.18.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Feb 2024 17:18:44 -0800 (PST) Date: Sun, 25 Feb 2024 17:18:42 -0800 From: Stephen Hemminger To: Tyler Retzlaff Cc: dev@dpdk.org, Andrew Boyer , Andrew Rybchenko , Bruce Richardson , Chenbo Xia , Konstantin Ananyev , Maxime Coquelin , mb@smartsharesystems.com Subject: Re: [PATCH v3] RFC deprecate RTE_MARKER in struct rte_mbuf Message-ID: <20240225171842.3798c6fb@hermes.local> In-Reply-To: <1707867209-1901-1-git-send-email-roretzla@linux.microsoft.com> References: <1706657173-26166-2-git-send-email-roretzla@linux.microsoft.com> <1707867209-1901-1-git-send-email-roretzla@linux.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Tue, 13 Feb 2024 15:33:28 -0800 Tyler Retzlaff wrote: > Here is the latest iteration of the proposed change to allow struct rte_mbuf > to be consumed by MSVC. > > * Introduce an internal __rte_marker macro conditionally expanded for MSVC > vs existing users of the struct. At some point we can uncomment __rte_deprecated > to assist migration away from the current marker fields for applications > after appropriate announcement periods etc.. > > * Introduce anonymous unions to allow aliasing of the previous named > offsets by a *new* name. The intention would be to convert the dpdk tree > to use the new names along with this change and enable __rte_deprecated > for dpdk builds (not applications) to avoid accidental re-introduction. > > * The anonymous unions are now also used to pad cacheline0 and cacheline1 instead > of __rte_cache_min_aligned. > > * Converted the type of the fields for the named markers to char[] instead of > uint8_t[]. > > Tyler Retzlaff (1): > mbuf: deprecate GCC marker in rte mbuf struct > > lib/eal/include/rte_common.h | 6 + > lib/mbuf/rte_mbuf_core.h | 365 +++++++++++++++++++++++-------------------- > 2 files changed, 201 insertions(+), 170 deletions(-) > I was never convinced that __rte_marker was good idea in the first place. It seemed to be only useful as annotation or for use by pre-fetch. The problem is that for annotation, it can easily be wrong if using different cache size or structure chagnes. For prefetch, just using the structure and pointer math based on cacheline seems like a better option. Plus DPDK does excessive and unproved prefetching. For real world cases prefetching doesn't help unless there is enough cycles from when prefetch is issued and when it is used. If too long, the prefetch is useless, if too close the extra overhead of the prefetch slows down the intervening execution units.