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 7B747A04A5; Wed, 9 Feb 2022 16:06:00 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3F1ED41144; Wed, 9 Feb 2022 16:06:00 +0100 (CET) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by mails.dpdk.org (Postfix) with ESMTP id 9D3B141143; Wed, 9 Feb 2022 16:05:59 +0100 (CET) Received: by mail-pf1-f178.google.com with SMTP id i21so3256155pfd.13; Wed, 09 Feb 2022 07:05:59 -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=svQuIunUQ/pH8po4UFnLb2jc2TiL9NGY5urf7ecJbhc=; b=OOiA4ZXNeaEDjqWAgTY8viZZDV7qdXyQ8+UzbmJ1mJ8oe8BGtPhWJ2KJKlU8mF6iFL vzHy45mm5cnffWyeb+upATcnU9UiE7lgmZHItygoOQ8tda1xZg66+ngURzSOQw+FNmBE ZValACHau9YW3uitIzf/2EYxCREjg3uQ+dzVhVZi5grwRTOUzrk7qNT/MfPyYhMVZBkO z7GzgzOnnsMl40QIVGFST2gBQQs2xp8oXb2q4jgDtDG7S4lFch1HfXXOUFsokFLNxR3E itiqwMAVkj+zpZAlKpMdwBzo183YHNPmAC2BHtz/S59Wqs4QQvxyyUj8qtOx0Ca1E7O3 KNbQ== 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=svQuIunUQ/pH8po4UFnLb2jc2TiL9NGY5urf7ecJbhc=; b=0IL3QEAlhaKB3ISQwFATeulUtm5oV4/N7mPUEP+7klSygxEdDOxVMWlan0JjGRhYqU rkVyoKPfVcKkEwsvfd62oP3o+gb9AmI2MaIkimc8rBjhnd7Rs+nhFo5NJGtGBL4xIzOX XlK5ekwnO93AeXuQLutEPbugsU3kjpV7HOaPml4opHezF4BDHX3mzSWqXV7QNnLZJ2oQ 9SycmZVpWmaiPrEGinjJFpYKDXumeapE2LhIkfEW8ovdG27Ioil9GzAyNWAn8gfZnBER JZo4OPSi01jMuknl3AdChYHQuq3TKPlt1sl6LfwCdMTJsvkEV8DXD1W1cCdXmPaxtZ7W N1cQ== X-Gm-Message-State: AOAM532pII6Ucwxh4tT64+9TjOEV4CHRjrePXvzJLlIXwP1jO2rQ+fYo e3WLg+KgcEBPjHQ7xaAn03TVzM6mquxCjpQz2vs= X-Google-Smtp-Source: ABdhPJxeTCm+1gsqTnIAf4pk8kvRR8X8sEUco3dad+qhXR6rAJ9bCIMkSEPbKZ47T00qMB7wRYCXess0dusIq8ihbrk= X-Received: by 2002:a63:698a:: with SMTP id e132mr2235911pgc.14.1644419158639; Wed, 09 Feb 2022 07:05:58 -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: Wed, 9 Feb 2022 10:05:47 -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 > > Calls to rte_memcpy_generic could result in unaligned loads/stores for > > 1 < n < 16. This is undefined behavior according to the C standard, > > and it gets flagged by the clang undefined behavior sanitizer. > > > > rte_memcpy_generic is called with unaligned src and dst addresses. > > When 1 < n < 16, the code would cast both src and dst to a qword, > > dword or word pointer, without verifying the alignment of src/dst. The > > code was changed to use a packed structure to perform the unaligned > > load/store operations. This results in unaligned load/store operations > > to be C standards-compliant. > > Still not sure we need to fix that: > This is x86 specific code-path, and as I remember on x86 there are no > penalties for unaligned access to 2/4/8 byte values. > Though I like introduction of rte_mov15_or_less() function -t helps > with code dedup. 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? I understand that X86 allows unaligned accesses but since this isn't assembly code, we have to go by what the C standard allows. 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. Thanks