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 7709FA00BE; Thu, 10 Feb 2022 17:56:44 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 18A48410E5; Thu, 10 Feb 2022 17:56:44 +0100 (CET) Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by mails.dpdk.org (Postfix) with ESMTP id DA62840140; Thu, 10 Feb 2022 17:56:42 +0100 (CET) Received: by mail-pj1-f42.google.com with SMTP id c5-20020a17090a1d0500b001b904a7046dso7622683pjd.1; Thu, 10 Feb 2022 08:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8DkMQJshJJfqSq8nHFvGAJCm9E3K4luS8DnYkMhqG0M=; b=c4+1iy4mbt+flJkKBxP6c/3mjefBUA5P2kgT/wvn3a91rdGXtLqsvWklMdQ3ejvqGl n18WRt/wK66ENZVCgxnI46pec1nAtGPJnJmoE1gfHFX4iuC5i9/9r0Wt5FexArCbs2yK OoDDxLpnQw8oC1s9UE5PbO4LzKp60DbJd3V+yWQ5LO+FoCAuGScpSUVW90JvLs5jH3mI OVokJHpxksyFAJgpZdvRHitium4cKZGbidT0rwUmGzgT++s9anh7PTYCDNvSxnemJM0/ rbvO3xWFdskzmXwBfSwnUMps5+LCZ4G7A6Vlig40ILkQu6bw4Ytsn6isNQc5xYDqB4vG KdDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8DkMQJshJJfqSq8nHFvGAJCm9E3K4luS8DnYkMhqG0M=; b=6+8LNbATgt65nBM6mjX4OJYJVrmygcv785/EtOYGm+9uhcONlciuvQ7vpNZz1iuUIS OrggBTAtNPfVOd36YaNSWfPH6GGKeD3iGsiILIbbr2w3f5e5NMB982hWM1+WSbQpslfX 8an/oR5z2nkau9BNjX8bBwMpRT5p2EYwmdS9FUuOYQqowo95nq/giW2B2VWffFazfDqw raZGpq1cuFAciy5El1O9aXywZVaZkNUmDAhiWcNxSueZr7XU6SzNf99McMYzEjXsvJ0J tG4mJnBWdMWtvK2S0f/7OvR+wiKBGsTLVLSNBghfPgmSlqhEgREFK2Dj/izsyHM4VF7c ua0Q== X-Gm-Message-State: AOAM533iSBwOgFP3VgTheUJhZARdkXNn3IH5/AD6Ri4+IT28FIiOb2b5 qsZzNn2QrT5M87IiJ5EDZcQTypt7JYcGZA9nExY= X-Google-Smtp-Source: ABdhPJxvuQNsNng0i8qTZlHvp56iApDl39/n+F0bJnGot+hRPAlqh3k64bhd9eNc7NlRnLDqhZJbTM+kQsoSXPKAW/0= X-Received: by 2002:a17:90b:1d03:: with SMTP id on3mr3760331pjb.54.1644512201970; Thu, 10 Feb 2022 08:56:41 -0800 (PST) MIME-Version: 1.0 References: <20220115194102.444140-1-lucp.at.work@gmail.com> <20220117153711.32829-1-lucp.at.work@gmail.com> In-Reply-To: From: Luc Pelletier Date: Thu, 10 Feb 2022 11:56:30 -0500 Message-ID: Subject: Re: [PATCH v5] eal: fix unaligned loads/stores in rte_memcpy_generic To: "Ananyev, Konstantin" Cc: "Richardson, Bruce" , "dev@dpdk.org" , "Li, Xiaoyun" , "stable@dpdk.org" Content-Type: text/plain; charset="UTF-8" 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 Hi Konstantin, > > Thanks for your input Konstantin. Much appreciated. Just to make sure > > I understand, can you please confirm that we do not want to fix the > > fact that unaligned access in C is undefined behaviour? > > Yes, I don't think it is a real problem in that particular case. Perfect. Thank you. > > Also, do you have any opinion on the strict aliasing violation (as was > > pointed out by Georg)? I suggested adding __may_alias__ thinking it > > would likely fix the issue, but I'd really like to get confirmation > > from someone who has better knowledge of how the attribute works > > exactly. > > Not sure I understand the problem you are referring to. > Are you saying that original rte_memcpy() code breaks strict aliasing? > If so, could you point where exactly? As far as I understand, yes, it does break strict aliasing. For example, in the following line: *(uint64_t *)dstu = *(const uint64_t *)srcu; IIUC, both casts break strict aliasing rules. While the src/dst parameters are void* and can therefore be cast to something else without breaking strict aliasing rules, the type of src/dst in the calling code might be something other than uint64_t*. This can result in src/dst pointers being cast to different unrelated types. AFAICT, the fact that rte_memcpy is "always inline" increases the risk of the compiler making an optimization that results in broken code. I was able to come up with an example where the latest version of GCC produces broken code when strict aliasing is enabled: https://godbolt.org/z/3Yzvjr97c With -fstrict-aliasing, it reorders a write and results in broken code. If you change the compiler flags to -fno-strict-aliasing, it produces the expected result.