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 3F4E843C06; Tue, 27 Feb 2024 20:06:09 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1361640279; Tue, 27 Feb 2024 20:06:09 +0100 (CET) Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by mails.dpdk.org (Postfix) with ESMTP id CC60A40150 for ; Tue, 27 Feb 2024 20:06:07 +0100 (CET) Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1dba177c596so784435ad.0 for ; Tue, 27 Feb 2024 11:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1709060767; x=1709665567; 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=pWcnFiL9KXOpPSEu43Ra9XlXppJmypgDehfa3WfIbPQ=; b=FCfnKghBQ+340ZNlJCMO+kQ2QPkQKfSgEe7rYylJrWJmPaPm7a12gmVgwFVfVnmJrG 8FFJqKP/8Hi5UZAw/2HzdCGwIKvXBc0ogb7IqLcUgOQg8hcbAAGVKtWATZ0V75vOMgNv wUU5woeQavXH5t5CsdTF5lEBkTF2Nx22IwEXZUwP+dLQe6V4c/qqNIWSsuELzF8rA9iT El05YaCvl8va4glYczq1wMM1DgGjss0CYoAclJjMI1xEyWlklATOCZhZQcnB6kdpQaZz bmgFvc2mynes4dfHXqaGr9skWAjI56f88zRihL2bncdMbc/A9ZocfURFEMODgH35xWxM StHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709060767; x=1709665567; 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=pWcnFiL9KXOpPSEu43Ra9XlXppJmypgDehfa3WfIbPQ=; b=aZp3ysGFC3RpnPhzAaNqdtmXqLRPbDZAHpz5gUfyR7yuvwcl2UYr6CcAcycAg1rL8B +r42NYME/lPa8Yitt5gZTiATwyZi0larFDXwKpj/5vWfhVsRhgSH7h9yIO32YCknbXcn 1w96rFIJ1p5TNgeCe7sSmZs+V+fB0BYY5ycA+fxxhhMTuBO3fIXy92Ot/uYUMeiOqYk5 BTka6zCpv5qyIqYp9G49IXrbI9xSNXSoxNylk0+G3zo/fAx3sHPtb/1nZ6kct3bi3MRb a0/DkdUymC11/MamehEVRDaX6Q+42dVMlf0E6nBAvrKBUt08iQj5CNSSS69dOrwL6h/D Er1g== X-Forwarded-Encrypted: i=1; AJvYcCVDCg/LY1ZB5u5rH6S/OPAVKQdjtv/CNJLpKJVqhorwydxIPR772Lw3hPvXlDLRySFc85BZZzSUR9kftY0= X-Gm-Message-State: AOJu0YxCumK5gouTTNnx0ci3f+Il81B3suyhPcLtg9pbL8gSJKOyySUy eFU0euS2OncbOxplM453ZaQae6uqYlaRSjzuJ4TkrvcP+xE1NWn5C2LFw7LTHbU= X-Google-Smtp-Source: AGHT+IEq212YGvTYbnocQi00oriiBoY8tkQELjb6wodqqhiM3OT+xLyKrz5CmR/PgFftgi9SsHHOtA== X-Received: by 2002:a17:903:2348:b0:1db:47bb:671b with SMTP id c8-20020a170903234800b001db47bb671bmr300025plh.19.1709060767038; Tue, 27 Feb 2024 11:06:07 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id e12-20020a62aa0c000000b006e5590729aasm218071pff.89.2024.02.27.11.06.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Feb 2024 11:06:06 -0800 (PST) Date: Tue, 27 Feb 2024 11:06:04 -0800 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "Jerin Jacob" , "Raslan Darawsheh" , , , , , Subject: Re: [PATCH v9] net/bnx2x: fix warnings about rte_memcpy lengths Message-ID: <20240227110604.56e19342@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F275@smartserver.smartshare.dk> References: <20240223140056.130844-1-mb@smartsharesystems.com> <98CBD80474FA8B44BF855DF32C47DC35E9F269@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F275@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 Tue, 27 Feb 2024 12:27:31 +0100 Morten Br=C3=B8rup wrote: > > > 1. The extra 2 byte copy is effectively harmless due to padding, as = =20 > > mentioned in the commit message. =20 > > > 2. The decorated rte_memcpy (if work on that patch series is ever res= umed) =20 > > is an improvement, not a bug fix, and will not be backported. So the me= mcpy > > parts of this patch are irrelevant for the stable versions. The function rte_memcpy only exists because glibc and gcc version of memcpy is not optimized enough. Would love to see it go away in future.