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 6A8D5A04A5; Tue, 25 Jan 2022 20:57:54 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0850241183; Tue, 25 Jan 2022 20:57:54 +0100 (CET) Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by mails.dpdk.org (Postfix) with ESMTP id 5619F41161 for ; Tue, 25 Jan 2022 20:57:52 +0100 (CET) Received: by mail-pl1-f182.google.com with SMTP id h14so3561524plf.1 for ; Tue, 25 Jan 2022 11:57:52 -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=UTZq+iNoVQ/Za7m5LGzIkzZMIWfZ+3uDKNAUrNQ1SCk=; b=GymKNC4Znr8caP6Y3uo+3Z9OoLAIP2yMndNcMDXSg15WUN/xHZziHw/I13R1staWBu 6c1VdB7VQbbPrxtFpyIjfpVRRgW2Q5v3jjyUM61l2Y2+4eB41AazQNYRkQ2cNkQdrDz+ Ci7qolXOeeA2ypvxc/vdzE2bCd9b0qlLJmeujzIF6xkQXDhy5knlqipbocBAiKAzK/aR 5IiaOe+k0cdgF3YHvv/m7Co9CrSa1i/OpSQ8bOub4JiwXJumw+fgIRNB/Y7iR8rzuar+ YFVjmVQaTB1jb6tHLNOqsyjl+q2pG6UrZIZUX6AQeXqbYdiSs9RCLc2ASbsHmfdeXqIE EYGw== 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=UTZq+iNoVQ/Za7m5LGzIkzZMIWfZ+3uDKNAUrNQ1SCk=; b=336K1O0f4X934dW/IJUzRpc2/s4soEk5+HkC9NcYwMv8hdBpy1knsO7XLS4QOyFD7s DvDsL3GW6RodXJHIm0nqSaXgU74tJFUtSWvIGqi+aBZR6RK11ksX9KbDTbMdjzIQpC0C 531NNJAq+6FAx5OGMmeQqbp71PmhlH1mtUTNsGOPcN/tZTEI9M2s36kDfJir2O+5lLWa PcZdRByT8vMZMQzVcwj4fjybxkqBWmw1dgIXrbb2/tdaBb0vzi/zmgGFXXcrQJRhEjQj 5ECIVv86eo8Jvk0L/jbxt/YyzyQi+DpDBwsv1Kuin3pLoy9uF5CLMct7Oclw8xX8kFwx FMfQ== X-Gm-Message-State: AOAM530tt2Mm/hpGFgezHiib82RlsNdbaQRkV9xM2IOtLnRHdt8qjtaM WdOP7ilPAHcg14Pqz6LDFR2lsXD+OJ2cxzdzpnA= X-Google-Smtp-Source: ABdhPJzb87io4Jo5yM5/yMZe15vNZ1mpSLLMDbtAtjlZRi7DSh+/r5EXjNku9DZrysHHTbHgXVM9tGm7caqnKJAKFAc= X-Received: by 2002:a17:90b:3b8a:: with SMTP id pc10mr5008650pjb.217.1643140671482; Tue, 25 Jan 2022 11:57:51 -0800 (PST) MIME-Version: 1.0 References: <20220116083220.2abe11b2@hermes.local> In-Reply-To: From: Luc Pelletier Date: Tue, 25 Jan 2022 14:57:40 -0500 Message-ID: Subject: Re: [PATCH v2] eal: fix unaligned loads/stores in rte_memcpy_generic To: Georg Sauthoff Cc: Stephen Hemminger , bruce.richardson@intel.com, konstantin.ananyev@intel.com, dev , Xiaoyun Li , =?UTF-8?Q?Morten_Br=C3=B8rup?= 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 Georg, > perhaps it's worth mentioning that the Linux Kernel is compiled with > -fno-strict-aliasing, because it contains code which violates the C > strict aliasing rules. Such code yields undefined behavior and is thus > unsafe when compiling with optmizing compilers such as GCC and Clang, by > default. But since the Linux supplies -fno-strict-aliasing its code is > safe, in the Linux Kernel context. > > In contrast, DPDK isn't compiled with -fno-strict-aliasing, in general. > Only a few drivers are built with -Wno-strict-aliasing. > > Thus, one has to be careful when importing (or being inspired) by the > above mentioned kernel defines. > > Especially, it looks like version 5 of this patch yields undefined > behavior because it violates strict-aliasing rules. > It's possible that GCC makes some extra guarantees for the used > constructs, even when compiling without -fno-strict-aliasing. But I'm > not aware of any. Thank you for pointing this out. That's an excellent comment and something I had missed. Would adding the __may_alias__ attribute to the unaligned_uint structs fix the issue? I think it would, but I have to admit that documentation is a little sparse and I don't have much experience with this attribute. If it doesn't fix the problem, please let me know if you can think of another solution that wouldn't involve going back to assembly (v4 of this patch). Also, I think the __may_alias__ attribute is supported by all compilers that DPDK supports when targeting x86, but please let me know if you don't think that's the case. > BTW, are there still systems that DPDK supports but have a memcpy() which > performs worse than rte_memcpy()? I concur with Morten, that's an excellent question. Analyzing the memcpy source code on every platform/architecture that DPDK supports would be one way to answer the question. However, that seems like a significant undertaking and I'm hoping someone who knows the answer will chime in.