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 208E943DDF; Thu, 11 Apr 2024 17:05:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 015AB402A8; Thu, 11 Apr 2024 17:05:36 +0200 (CEST) Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by mails.dpdk.org (Postfix) with ESMTP id 6C1354029B for ; Thu, 11 Apr 2024 17:05:34 +0200 (CEST) Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-6ed5109d924so3379432b3a.0 for ; Thu, 11 Apr 2024 08:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1712847933; x=1713452733; 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=MefHmObaVusvkCDJ6e7PHEI/X7eO5aUnY1Nw6mfg7zE=; b=iTsKvv9/D7RgxDZq+1nv9FbxJG5f8IgBbXKg7+OFiFHqyiQQp8HNvwGHVInSEGaZ1D +KRPfqMapB004JoPWkNVf8C9ktAtsUHS1yI+Wig/I+aGpJYV4BsYVaGjRcUxg8lDXpw6 XbScNjRLrnVSFzUFD2oLA15rqY2zyu9A3p2NrVlr12RN6CBEp6xj/9H9ou/GgxCLSqin 5uPd67NYZLhke53RTt++80yDKE3TrUfKT+63ImUtL9dcFqdNmt95LVjUlJ+cOYhXHVRE YQM0QAwnAoV4YFmV6JeTjWPNnFTAWQLm8pMXZ11AdY/aBUlYRJCW9PRDKLmMHMH9uo3t xQFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712847933; x=1713452733; 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=MefHmObaVusvkCDJ6e7PHEI/X7eO5aUnY1Nw6mfg7zE=; b=Nb9zz57DY065vDklAi+de8aiXVhoIurucssOQ5asHBaqRvYyGpIhDyyID/Hq0t3PTK O3nYsXxa2RM3zdoWtk7FfBg5MUV2rGlM6r0KMvUrQupQhl3gZ0zBRc0klSTofXMLr1jC rfzBLxTkC8ZDpLqQMfB3JhevpWxpITAbGxD5RxzNSG7sOF7fl+AmxSxo+4nv5gGgTtJz sixGMQaT3XAsLx7VywETjxOFJ8OD+iAp27/4RtYfj8XlHA4WwmwU8r488LnNMLMJkVCh J/1uTlKV80YPh8upwgHD3WClqg2zMocyP12sc/M1o1bq45H02B0UrvNx6icIm9uKQ+Lq A86g== X-Forwarded-Encrypted: i=1; AJvYcCVG9oyvwvGR6Zj5tVYmWvgdLlMYSPa9V77t1P0n1LwDOAwdMH/mVZ2wRpTm06pHDMbgHMNXECaZIKyemEA= X-Gm-Message-State: AOJu0YwkXaJ3TH4YKiolSPwV4RVuUXnh7kLp+/uZ/bpqQ4TWvRGIOfW4 VDLVqoQIFngFZ7l/s3JEmmxd55FE+ZR7+edJInvRq3dj9mJO0DFA7Of1f186Fzo= X-Google-Smtp-Source: AGHT+IEcemcObhPosNXAzc5V4IdC2fh8/ZbM16QwruvXmsa99+gv+gefJnwWOWPX+HtP4KVHQmgrNg== X-Received: by 2002:a05:6a20:da93:b0:1a7:5335:450e with SMTP id iy19-20020a056a20da9300b001a75335450emr150044pzb.0.1712847933401; Thu, 11 Apr 2024 08:05:33 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id b65-20020a633444000000b005dccf48e2a5sm1186338pga.54.2024.04.11.08.05.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Apr 2024 08:05:32 -0700 (PDT) Date: Thu, 11 Apr 2024 08:05:30 -0700 From: Stephen Hemminger To: Chengwen Feng Cc: , , , , , Subject: Re: [PATCH] ethdev: fix strict aliasing lead to link cannot be up Message-ID: <20240411080530.1f5030c6@hermes.local> In-Reply-To: <20240411030749.41874-1-fengchengwen@huawei.com> References: <20240411030749.41874-1-fengchengwen@huawei.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 Thu, 11 Apr 2024 03:07:49 +0000 Chengwen Feng wrote: > Fix a problem introduced by a compiler upgrade (from gcc10 to gcc12.3), > which will lead the hns3 NIC can't link up. The root cause is strict > aliasing violation in rte_eth_linkstatus_set() with hns3 driver, see > [1] for more details. > > This commit use union to avoid such aliasing violation. > > [1] Strict aliasing problem with rte_eth_linkstatus_set() > https://marc.info/?l=dpdk-dev&m=171274148514777&w=3 > > Cc: stable@dpdk.org > > Signed-off-by: Chengwen Feng > Signed-off-by: Dengdui Huang > --- The patch to use union is correct. Examining the link status fuller raises a couple of pre-existing issues. 1. Why is this an inline function, there is no way this is in the fast path of any driver or application? 2. Why is it marked sequential consistent and not relaxed? How could there be a visible relationship between link status and other variables. Drivers would not be using the link status state as internal variable.