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 8241543313; Mon, 13 Nov 2023 00:31:52 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0236F402AB; Mon, 13 Nov 2023 00:31:52 +0100 (CET) Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by mails.dpdk.org (Postfix) with ESMTP id 3F8474029A for ; Mon, 13 Nov 2023 00:31:50 +0100 (CET) Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1cc329ce84cso34259675ad.2 for ; Sun, 12 Nov 2023 15:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1699831909; x=1700436709; 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=vq8v3r5iSOzu5caOmfbBGYIqAT8fRObBJ0Gs1cfucWM=; b=ma2aa0c+FrPYeP5tFSL69KV+XvxJL/n+koa5Gb1pdXbAp5vxWUGIQmwOmlfvdiQwg1 me6rKfmsiOlqpXBYJqFrwwBwl4JqN1pkbGj4MYnC0sw0MEhYfmiwuw6VjY8JT9NnLxNZ kQIbp5rAuZ6kGXUFuPCe3yrG7rn2+c1LucvMrfe0ZSn/xxs/Nclfwpz+U/qqF+TL4MdW FRWa/LjmvkC2v2niDbtyDtp10BY1eih9x70+kPhZeQYRmT9KFl9HkTFsf58wh1dxrktu 7nMsxHWL8JG/jNOaW8TdO/yvN9ppEaFjwDhxlXGn1qTC2JxR2rQg3Y0s+Kp6tuITJCcZ 0oZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699831909; x=1700436709; 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=vq8v3r5iSOzu5caOmfbBGYIqAT8fRObBJ0Gs1cfucWM=; b=UvV5mI/sdeqHw1g2B4YmWfhGbC9fFEOekB9i+urVLnNB/EoU8lRVa+K4pkALXRk9DT Z4RklFgMpYE4XEuWdhtAvizFaRuzTaWfKH5I8/qw0lmpO6sykZ3w2l3uMl1H6bOaboOO DTJnpTHbY+MzMabgYIRXoeVb8aCf8ugqq6w/zTValWl5UBE3/wldkdarKrmPre8bHnoQ SPhP/qsgDVXOXg+QFxWmyofNYFxnqrmHBe7QefSfDLRBZSy68fKoypzazf/K6ZtpNsqW x8L/wNdIvWH2vtTUKpF6DjuLjAex++MpXgc3FHCFVDQQT06GW0f9pkox2Voc0P9yqFcd 7Obw== X-Gm-Message-State: AOJu0Yzseu6VdWhPCjuiiY371x1BuuByP8XHN0tYgFPfQpep7AwClb0h +/b9t2GjGCoKDoWykhl3ZDT3mw== X-Google-Smtp-Source: AGHT+IFcpW363O+YMJKcDGBjFBZeRyssC3smSjfwidiHY4V0NzHpvdJ3mJWy98GrRJoDRTLY70fMIg== X-Received: by 2002:a17:902:d485:b0:1c7:2740:cfb3 with SMTP id c5-20020a170902d48500b001c72740cfb3mr7110614plg.35.1699831909109; Sun, 12 Nov 2023 15:31:49 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id bc6-20020a170902930600b001c61e628e98sm2972477plb.175.2023.11.12.15.31.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Nov 2023 15:31:48 -0800 (PST) Date: Sun, 12 Nov 2023 15:31:46 -0800 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "Bruce Richardson" , , "Jerin Jacob" Subject: Re: [PATCH v4] eventdev: ensure 16-byte alignment for events Message-ID: <20231112153146.5fdd72b8@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F016@smartserver.smartshare.dk> References: <20231005115101.12276-1-bruce.richardson@intel.com> <20231006102932.164630-1-bruce.richardson@intel.com> <20231111160104.49360157@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35E9F016@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Sun, 12 Nov 2023 09:30:24 +0100 Morten Br=C3=B8rup wrote: > > > +static_assert(sizeof(struct rte_event) =3D=3D 16, "Event structure s= ize =20 > > is not 16-bytes in size"); =20 > > > + > > > static struct rte_eventdev rte_event_devices[RTE_EVENT_MAX_DEVS]; =20 > >=20 > > Please don't reinvent RTE_BUILD_BUG_ON(). > > Instead fix that to be a static_assert() =20 >=20 > I would say the opposite: > With our upgrade to the C11 standard, let's get rid of the RTE_BUILD_BUG_= ON() workaround for the lack of static_assert() in older C standards. >=20 > Unfortunately, the static_assert(expression) variant without the "message= " parameter, which would make our RTE_BUILD_BUG_ON() macro completely obsol= ete, requires C23. And I don't see how we can make this variant available w= ith C11. So we probably have to wait until DPDK requires C23. >=20 > Until then, let's gradually phase out the DPDK-specific RTE_BUILD_BUG_ON(= ) in favor of standard C's static_assert(), and live with the inconvenience= of having to provide a message parameter for it. >=20 > Please also note that static_assert() can be used outside code blocks, wh= ich makes it handy for use in header files. If you look at my RFC, the message is just as good as the one in this code. It ends up being stringified version of the expression. Which is more exact= than the wording used in some other places.