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 3880DA0547; Thu, 29 Apr 2021 13:53:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E7890410DD; Thu, 29 Apr 2021 13:53:33 +0200 (CEST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by mails.dpdk.org (Postfix) with ESMTP id EC9C8406FF for ; Thu, 29 Apr 2021 13:53:31 +0200 (CEST) Received: by mail-lf1-f54.google.com with SMTP id n138so104492835lfa.3 for ; Thu, 29 Apr 2021 04:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=LdGECphkJsfQ5ZyEMUThYivKYL0YQXcKwndCCxFb9W4=; b=npC18OH/SnSxmRDLRNBF3XKptMPWfePSCaDyuTCH3CC2F0PS6Jn5Tnsl2WtKa8kyeW MkrQBW9/bEbUsK8H9wBdjPFF2yvFRCoxvpFBIRS4WiOH+be7vU7AfTT/DIlhvXq+DNM+ SnvMDrtBC/loao6kAWTFZxhh2DHO+eWoLv9hG7/+YsKU0d8vhVIzik8DAvWcBHeqhJfm WGb/oKPmvO3UwrP8hKGWBSDiLfIaoAU98hwucMNkNdeybg13/utHsXTJd9W5rGor4QtU 0g7TqXsO3DP9TY51D6hLEtS5uLxb7W09xOLXAKAvK+975mSRKePCJsy/f2sv1ZCfYpBj v8XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LdGECphkJsfQ5ZyEMUThYivKYL0YQXcKwndCCxFb9W4=; b=nYKy/VzatshZ/DAJhVPnfhrpM+rcGi8XuKRMADpQ6gEZvF//Sjrjt//Yzzvwe32kNx uSijbcJ4kTTpWQ2PVqRDFA34N3hEpdn6A8elB8CiXnqHp8qcD8XqErVZJIZ1gsiUky5w gWN0K6bbvujcpnEttGKwxCRuY76ZNkOlTLXWO6x7Raq1qNepKMDHhxx5eNNTHM7DN68f Z1KIATfhgoew06dq2TN08J29f4A95pRzUEs7VdSan22J4gcxBL73TQPrbl/Nlspp3rC7 BXNUUbObBGwL2z0gdJ4HJtP8QMmt+0UgGo94oZuR6ARvfTpyOwtl/Oxgmfztn3VTRhYe rAzg== X-Gm-Message-State: AOAM532vUK1EEnHq+t6vTS+vTT7H+urlPDgGLqEc7hb/fPJK0JcOntxV 7iEiQOWoOfvYukszWwFGuCtm+g== X-Google-Smtp-Source: ABdhPJwIAFDlLOxwNC7Rw8GfWWqFqtgeHQBN1mqATXPklGeeA3E9jyBk5GlFNCj3hK4xaeh63yhnPQ== X-Received: by 2002:a05:6512:3da1:: with SMTP id k33mr19354899lfv.135.1619697211558; Thu, 29 Apr 2021 04:53:31 -0700 (PDT) Received: from toster (89-73-146-138.dynamic.chello.pl. [89.73.146.138]) by smtp.gmail.com with ESMTPSA id e17sm504084ljn.29.2021.04.29.04.53.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Apr 2021 04:53:31 -0700 (PDT) Date: Thu, 29 Apr 2021 13:53:29 +0200 From: Stanislaw Kardach To: "Ananyev, Konstantin" Cc: Honnappa Nagarahalli , "Richardson, Bruce" , "Yigit, Ferruh" , Stephen Hemminger , Jerin Jacob , Kathleen Capella , "thomas@monjalon.net" , "dev@dpdk.org" , Dharmik Thakkar , Ruifeng Wang , "david.marchand@redhat.com" , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , Stephen Hemminger , nd Message-ID: <20210429115329.a2zek6rkmna6qhs3@toster> References: <81781e97-735c-f584-4148-ff07dedc5cb4@intel.com> <20210429074945.alquywrvyxjdezqi@toster> <20210429103922.7jw2e24qemsd4y3y@toster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] L3fwd mode in testpmd 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 Sender: "dev" On Thu, Apr 29, 2021 at 11:47:30AM +0000, Ananyev, Konstantin wrote: > > > > It looks as if implementing em_mask_key() is enough to get l3fwd > > working. However to me this ifdef seems tricky. How should a scalar > > implementation handle the xmm_t type? rte_xmm_t looks like an API > > type/union, but both are not mentioned in documentation and are in > > platform dependent rte_vect.h only. > > So either I add another case for RISC-V or (what seems more proper) add > > an else clause implementation. However then should I change this function > > to take rte_xmm_t? If not is casting xmm_t to i.e. int32_t[] always > > valid? Even if I change to rte_xmm_t, it's not a stable API type, is it? > > So what guarantee do I have that it maps to int32_t bit-wise on every > > platform? > > > > I think the semantic requirements of xmm_t typedef are a bit undefined as > > well as the vector handling across the architectures (being something > > rather arch specific). I don't have a clear idea on how to solve this > > yet and I would not like to hijack this discussion with vector stuff. > > > > Though I may be missing some obvious solution here. Any idea is welcome. > > :) > > I think it should be possible to replace xmm_t with rte_xmm_t in ipv(4|6)_5tuple_host > and make em_mask_key to take 'rte_xmm_t *' as a parameter/return value instead of xmm_t. > With that in place scalar version seems straightforward. > Of course perf regression test would be needed after such changes, > but I think with '-O3' it should be no difference. > I did that and it works in practice. I'm more asking about the lack of definition in rte_xmm_t semantics. Because once it's in an example, people may start assuming it's OK to use it this way. If it is OK, then I'll just post a patch, otherwise we need a separate discussion. -- Best Regards, Stanislaw Kardach