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 CB255A0583; Fri, 20 Mar 2020 09:23:54 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AE0301C023; Fri, 20 Mar 2020 09:23:54 +0100 (CET) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id 5F9CAF94 for ; Fri, 20 Mar 2020 09:23:53 +0100 (CET) Received: by mail-il1-f195.google.com with SMTP id h3so4820621ils.3 for ; Fri, 20 Mar 2020 01:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xIl1myQs4JSmgimaaomMXD3b2Y4qdKacMyHdsUpB3io=; b=E7l34fvibjpSo/YuzveM4CYnLh9OH5qRgmkwZooUDYd54/4iXbNSva9MjtE0oGdp8S Jg1lugLtx7YMS2dvz9UUcc0NTzPRpqSRaMY+5JSoasRSB4aof9TlYqKow8Y94sbzzk62 PjHDtRFo8hmANkmyB6x+A8bzBqgoGoG8YT+X6L0k8xdLBKpip5k4tTIoetuZrlpE8XZZ xb6dutOMjA5NoBy1TuY/GNbcNS2eU3AlAYgW1KMagt0eEfhpFu5uiamnsrd9stwGftI4 ehLh9Uo+BVfGTKE4XdfwMHYMzcSgRzP7saVfqOVwFR6xJsTCYh7EUo358zx6JT0Eod1j n6LQ== 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:content-transfer-encoding; bh=xIl1myQs4JSmgimaaomMXD3b2Y4qdKacMyHdsUpB3io=; b=mvqE2zDx8sE/YxawMqMqfOlm+9ildAAbeSnZ3/vwaWljoqBgx2gAlLFtM4JwEgp7k4 rAJTm6Ppms6MTJgZBC7K1TWSxzCgKkXsdl6fsWHaOjE8l6XuJ2kXhKkrw41r5cA/oOeA QzBbpb9/+zYSRx7+c3x3GjE2NJlK+/wZHtu24ZS8Rkek3XR98FnLIXEXmpwu+EJ+vJBw YjkwJ3vRdZMDs3T9tWA2uULuQf5AVYIUjYay9P0XQM2LySM5IVdJt0pXkLpDF01V456S lBHudnXoxffiy6oR/RpyGQaZqAGd2xvbWqep9KWT6txZy7iDAvCFpMqfU4tIPHMibF7W aRBg== X-Gm-Message-State: ANhLgQ2sAeVcvmknD6erBLFD2bKJYuCdXts9F4EPRoPSo+RrqkPPHYA9 zR0KwpENCSmoif76DkXLKsBrlV12SRhHKw0Khk8= X-Google-Smtp-Source: ADFU+vsCyMscF/ggj+XiMOV07LAG2MjauXDXdCYsZhm7JPJlRosmD9R1a9d/ANaKN5+6s/2Ir/pMNQKJ3YYfj03Dy9g= X-Received: by 2002:a05:6e02:90:: with SMTP id l16mr676350ilm.294.1584692632571; Fri, 20 Mar 2020 01:23:52 -0700 (PDT) MIME-Version: 1.0 References: <1583757826-375246-1-git-send-email-vladimir.medvedkin@intel.com> <1583757826-375246-2-git-send-email-vladimir.medvedkin@intel.com> <9e4b3980-e1b5-2bfd-d551-bfa8ad022e50@intel.com> In-Reply-To: <9e4b3980-e1b5-2bfd-d551-bfa8ad022e50@intel.com> From: Jerin Jacob Date: Fri, 20 Mar 2020 13:53:36 +0530 Message-ID: To: "Medvedkin, Vladimir" Cc: dpdk-dev , "Ananyev, Konstantin" , "Richardson, Bruce" , Gavin Hu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH 1/6] 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 Tue, Mar 10, 2020 at 8:14 PM Medvedkin, Vladimir wrote: > > Hi Jerin, Hi Vladimir, > > Are we missing __attribute__((aligned(64))) here? > > Agree. While modern compilers align __m512i by default, some old could fa= ilure to align. Please correct me if I'm wrong. Yes. > > +} rte_zmm_t; > > IMO, Due to legacy reason, we have selected rte_xmm_t, rte_ymm_t for > 128 and 256 operations in public APIs[1] > > As for me, since these functions are inlined, prototype should be changed= to uint32_t ip[4] instead of passing vector type as an argument. OK. Makes sense. > # Not sure where xmm_t and ymm_t and new zmm_t come from? Is this name > x86 arch-specific? > > Yes, that's why they are in arch/x86/rte_vect.h See the last comment. > > If so, > why not give the more generic name rte_512i_t or something? > # Currently, In every arch file, we are repeating the definition for > rte_xmm_t, Why not make, this generic definition > in common file. ie. rte_zmm_t or rte_512i_t definition in common > file(./lib/librte_eal/common/include/generic/rte_vect.h) > > I think there could be some arch specific thing that prevents it from bei= ng generic. > > # Currently ./lib/librte_eal/common/include/generic/rte_vect.h has > defintion for rte_vXsY_t for vector representation, would that > be enough for public API? Do we need to new type? > > Definitions for rte_vXsY_tare almost the same as compiler's __m[128,256,5= 12]i apart from alignment. > Union types such as rte_zmm_t are very useful because of the ability to a= ccess parts of a wide vector register with an arbitrary granularity. For ex= ample, some old compiler don't support _mm512_set_epi8()/_mm512_set_epi16()= intrinsics, so accessing ".u8[]" of ".u16[]" solves the problem. Yes. We are on the same page. I think, the only difference in thought is, the x86 specific definition(rte_zmm_t) name should be something it needs to be reflected as internal or arch-specific. Earlier APIs such rte_lpm_lookupx4 has leaked the xmm_t definition to public API. To avoid that danger, please make rte_zmm_t as internal/arch-specific. Something __rte_x86_zmm_t or so that denotes it is not a public symbol.