From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0D317A0528; Thu, 9 Jul 2020 17:20:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DABB51DB74; Thu, 9 Jul 2020 17:20:40 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 588921DB65 for ; Thu, 9 Jul 2020 17:20:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594308038; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qQm0rRCubEjLN/ZTkibXmFaoHxEtTd7JgJcBki7auYQ=; b=Jci6uiXfjuco3hjx8U2lj0i6C6yax9fdMVX5r592L/TAaXhSZjyHXccVUYaqnG14dYiUdo gTC6i7B+LQgfZTof4xdESrUEA9Re5ULwnjr7SPTk4Rd6k3RLM7yYjX6zwfHoLjGUoNh4Xt QnjhOf0DTisY4n+dBH0T+yN+xw8OFn4= Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-364-dzlT5GLBMnWaSWFgzJ50KQ-1; Thu, 09 Jul 2020 11:20:21 -0400 X-MC-Unique: dzlT5GLBMnWaSWFgzJ50KQ-1 Received: by mail-ua1-f70.google.com with SMTP id c14so989705uap.16 for ; Thu, 09 Jul 2020 08:20:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qQm0rRCubEjLN/ZTkibXmFaoHxEtTd7JgJcBki7auYQ=; b=BwRoV4MIWwXG6YZyAQP6KGxMZNpK0xEVGMFWlwNBaYoNVMIpydYB16rD2RvLYM5kmF tWg2QufcMB6ULDQjUAFQ+qn6RwXE5Lg//IZ90gklyodAj6pcgU4b38N8+vqvv1lsnwCh l8qz6T0iTqO8CQbuwk2TvD75ECHv9/hpFVrC+p8j8MuUMsyjUwNbZ/7NMu2eS5Elze4a gQr3e+RS199J/T647PcZ2ZFPOGPFsyzjvWFRPib8u2FMkspdUaOpIAiLTkIzjdVrLyHm 3h/fozHBqf4/5I0kzcH9dBfi5Hbsh/WYAWbRPL6mcQVwuz5dcAmuy2rlCpvkmWjPBLIR fiCA== X-Gm-Message-State: AOAM530OnswQ2hOx4ZCC72bUjr/xkO8plHldbzBV5DLoVCROIAZX1fme uL8N0wrxAiZg2q8aOHxiY5paKcFi0RAv9iTW53AwnQY+B9f1SMH3Yx+gDCmhBMCNaVulhEsvEkB gb/m1TzEICdU+uSS4NQc= X-Received: by 2002:a05:6102:249:: with SMTP id a9mr18632192vsq.198.1594308020872; Thu, 09 Jul 2020 08:20:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy46ss9utIH+pOv93ZKjSXd5oug/Xbb6kHLQR5fg7BWSq5QVyMKHLnKWPa4k6Zb9Lm2EZVG18JD5kO1HuXckRE= X-Received: by 2002:a05:6102:249:: with SMTP id a9mr18632169vsq.198.1594308020595; Thu, 09 Jul 2020 08:20:20 -0700 (PDT) MIME-Version: 1.0 References: <98b10e12eb46cff65494a94eaf0f04b2dcefd245.1594238610.git.vladimir.medvedkin@intel.com> <3f68ec75-417b-1587-e13a-07cdeb5056e9@intel.com> In-Reply-To: <3f68ec75-417b-1587-e13a-07cdeb5056e9@intel.com> From: David Marchand Date: Thu, 9 Jul 2020 17:20:09 +0200 Message-ID: To: "Medvedkin, Vladimir" Cc: dev , "Ananyev, Konstantin" , Bruce Richardson X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v4 1/8] eal: introduce zmm type for AVX 512-bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Jul 9, 2020 at 4:52 PM Medvedkin, Vladimir wrote: > >> + > >> +#define ZMM_SIZE (sizeof(__x86_zmm_t)) > >> +#define ZMM_MASK (ZMM_SIZE - 1) > > > > Macros in a public header need a RTE_ prefix + this is x86 specific, > > then RTE_X86_. > > > > Looking at the whole applied series: > > $ git grep -lw ZMM_SIZE > > lib/librte_eal/x86/include/rte_vect.h > > $ git grep -lw ZMM_MASK > > lib/librte_eal/x86/include/rte_vect.h > > > > So I wonder if we need to export it or we can instead just #undef > > after the struct definition. > > I think it's better to undef it Even if you undef the macro, please still prefix it. This is to avoid conflicts with macros defined before including this rte_vect.h header. > > > > > > >> + > >> +typedef union __rte_x86_zmm { > >> + __x86_zmm_t z; > >> + ymm_t y[ZMM_SIZE / sizeof(ymm_t)]; > >> + xmm_t x[ZMM_SIZE / sizeof(xmm_t)]; > >> + uint8_t u8[ZMM_SIZE / sizeof(uint8_t)]; > >> + uint16_t u16[ZMM_SIZE / sizeof(uint16_t)]; > >> + uint32_t u32[ZMM_SIZE / sizeof(uint32_t)]; > >> + uint64_t u64[ZMM_SIZE / sizeof(uint64_t)]; > >> + double pd[ZMM_SIZE / sizeof(double)]; > >> +} __rte_aligned(ZMM_SIZE) __rte_x86_zmm_t; > > > > I don't understand this forced alignment statement. > > Would not natural alignment be enough, since all fields in this union > > have the same size? > > > > Some compilers won't align this union > https://mails.dpdk.org/archives/dev/2020-March/159591.html Ok, interesting, I will try to keep in mind. -- David Marchand