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 9E97643B6F; Wed, 6 Mar 2024 18:22:49 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 28F8142DBD; Wed, 6 Mar 2024 18:22:49 +0100 (CET) Received: from fhigh7-smtp.messagingengine.com (fhigh7-smtp.messagingengine.com [103.168.172.158]) by mails.dpdk.org (Postfix) with ESMTP id 4FFD042D96 for ; Wed, 6 Mar 2024 18:22:47 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfhigh.nyi.internal (Postfix) with ESMTP id D2D7111400FE; Wed, 6 Mar 2024 12:22:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 06 Mar 2024 12:22:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1709745766; x=1709832166; bh=JXGszlpyZVmO2Oh5il+1C6kGthjUhsP0uLMOUyGzgAE=; b= b0LS2O6agEAKcp2SKEGnRw5kjUrxla5b7NmW9kzSOMFbUDL5j1+sHuOK4+Ij/5jL e5CjvduiTGMCSCmfYzz4Q6qJqDxqqV4k8L4PLzEipWdj3B9xVJ9P7WY3A25QuuT3 0YdvYxiuo5sSavDQXdn7Tu346COJp2chEhar1ECpjlhFeLZqE8Ua7in0wLZeH3TF yUtwDz1JSkIgNEHGZEic9/w0wvyhaARiUi1WcpHjLO85g8iGVQo0Z29uj0J/nUL/ /vTn0UYJN8NpjB9iFAdX+WmZUV4N8Vh/WavGV5o5+2kaDd2GL1oWcV0Fk9mKyM3e aOTxuUFV+JCKzKVjb4a5fg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1709745766; x= 1709832166; bh=JXGszlpyZVmO2Oh5il+1C6kGthjUhsP0uLMOUyGzgAE=; b=i vt/Z7pDIhb4XsxT3Tkbc0qQ9XsFMvjb/mXNtXPCQ+g/iaj1qCHbYfV2jUY4ARoxS j/KPh4988UE3xtV9ECp7GlLF7sYAzOgX/1X8gK66ifksIE9XzS7/l7Vqr7R6GCZ4 GyMyve2zx9VJytcoZF1XTeThc/ZJJvDYeVRVLKi0jhfnPP4YhsBpLsqRl+8tdSGS zLgi0OAQUPoj/R/UHLCkuJzO5WqtQvQkCRWGgm+srMoxStiNMivq3+s93Ti1vVoV Xur/GqIqyAN1X+UBe721h7vE3BjZiaxOsh55jymRbWAF/7P+aZbH3us83v1Ne6gR OMkufZOmP0ENZYnVTAsNQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledriedugdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 6 Mar 2024 12:22:45 -0500 (EST) From: Thomas Monjalon To: Stephen Hemminger Cc: dev@dpdk.org, Tyler Retzlaff , Yipeng Wang , Sameh Gobriel , Bruce Richardson , Vladimir Medvedkin Subject: Re: [PATCH v2] hash: make GFNI stubs inline (again) Date: Wed, 06 Mar 2024 18:22:43 +0100 Message-ID: <13465891.y0N7aAr316@thomas> In-Reply-To: <20240305030819.276707-1-stephen@networkplumber.org> References: <20240304184508.89956-1-stephen@networkplumber.org> <20240305030819.276707-1-stephen@networkplumber.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 05/03/2024 04:07, Stephen Hemminger: > Tyler found build issues with MSVC and the thash gfni stubs. > The problem would be link errors from missing symbols. > > This version puts back the rte_thash_gfni function stubs as > inlines, but instead of logging a message, they panic. > This is intentional because any application should be checking > with function rte_thash_gfni_supported() before calling the > hashing functions here. Better to panic then return zero > and put out log message which will be ignored... I want to be able to grep rte_panic in the lib directory to find those we should remove. Having "legit" panic calls is a no-go for me.