From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it1-f195.google.com (mail-it1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id BE4EF1B5FD for ; Thu, 10 Jan 2019 12:56:00 +0100 (CET) Received: by mail-it1-f195.google.com with SMTP id h65so15830678ith.3 for ; Thu, 10 Jan 2019 03:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MQL9OBwDCfO1EIBiPuZf7lIBQicaF8/0iOjjJ90D37A=; b=u/+2ljEfBkGBkUtsaZJTE3z8P3jayMyVH4Vb6uwaG0RhD07AJwD0qgwA2cC2i69Kg0 dpOiXINLJoXPSEN5umYGQwYOnku0Bi0VdaxKTMRdv3zXilTeNc5tp2a1AGD7wUzpkYlB hqWGMCOy6Em5NCjcRvnUQdQs+cupxDncOgwrLg2qwJsFpMgLeVQySjtQ6o/MjkWObxwV iX2g1pK5EhUrP58MbmJ+I11F/km7nbarAxKc0eGst4AlAstOQs5nfVqa8EBnGH0BaWQL ECuHdJNhymdfujSNBp5Nw5b9/wFO6+c1Z6SzuKNbekch+N4LipyKuZt2RcflvVH9GD8p /67A== 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=MQL9OBwDCfO1EIBiPuZf7lIBQicaF8/0iOjjJ90D37A=; b=MS220Aei/4yeCWcVeEgFIGVaBDadtAcpIph8n+ktRzlGpG01jBmbplmZNVui8FTQr9 wdx3ggGO+cOL4H4hsX67a1ke3VHbpBmyh3WK86Cu8r77ojb7aUaNOEUFBmbfptSlWpLP LlVucJq5U5YWk49jHPeFPLDrrJ5Fp7mGiF9ElfmNZzvk0UEJlUA6Pt79xr2CV1O9I82I 54dl358ZTfan83SUhxewQTMVfcLF2e62U7Gv54eQzH2RiveBzMb9Ub5jTvySovX6ApYR VMSvr/Oo8kDC606oUW2OMUuyFzr/GoTZhby6ckQ9WCJzTy/gmbIvlqf610nh9TpCITYm hU2Q== X-Gm-Message-State: AJcUukdkAfvAgyk3ZqnqEAQBoLFvSxWATp/U9vBgccDIPfuVPPBDhFB0 4iHow9Ir+KbsIO88jMFnOzwlQw7QweYHyDiy1hENig== X-Google-Smtp-Source: ALg8bN6NHjn76QwZBOvpnqUSF+FH6azcPuDHnS1m+CEY9BHGV1NfuxjXPLFAMMJ0aC4OLlvQrkpTNvxYZ9ihM5uofjs= X-Received: by 2002:a24:1495:: with SMTP id 143mr6437475itg.13.1547121360087; Thu, 10 Jan 2019 03:56:00 -0800 (PST) MIME-Version: 1.0 References: <20190103085621.23611-1-alejandro.lucero@netronome.com> <09fd5132-905b-bbe0-1178-392595027353@intel.com> <9afed691-6710-7efd-09e7-ae927cc091a8@intel.com> In-Reply-To: <9afed691-6710-7efd-09e7-ae927cc091a8@intel.com> From: Alejandro Lucero Date: Thu, 10 Jan 2019 11:55:49 +0000 Message-ID: To: Ferruh Yigit Cc: dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] net/nfp: add CPP bridge as service 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: , X-List-Received-Date: Thu, 10 Jan 2019 11:56:01 -0000 On Wed, Jan 9, 2019 at 4:15 PM Ferruh Yigit wrote: > On 1/9/2019 2:20 PM, Alejandro Lucero wrote: > > > > > > On Wed, Jan 9, 2019 at 10:54 AM Ferruh Yigit > > wrote: > > > > On 1/3/2019 8:56 AM, Alejandro Lucero wrote: > > > The Netronome's Network Flow Processor chip is highly programmabl= e > > > with the goal of processing packets at high speed. Processing uni= ts > > > and other chip components are available from the host through the > > > PCIe CPP(Command Push Pull bus) interface. The NFP PF PMD > configures > > > a CPP handler for setting up and working with vNICs, perform > actions > > > like link up or down, or accessing extended stats from the MAC > component. > > > > > > There exist NFP host tools which access the NFP components for > > > programming and debugging but they require the CPP interface. Whe= n > the > > > PMD is bound to the PF, the DPDK app owns the CPP interface, so > these > > > host tools can not access the NFP through other means like NFP > kernel > > > drivers. > > > > > > This patch adds a CPP bridge using the rte_service API which can = be > > > enabled by a DPDK app. Interestingly, DPDK clients like OVS will > not > > > enable specific service cores, but this can be performed with a > > > secondary process specifically enabling this CPP bridge service a= nd > > > therefore giving access to the NFP to those host tools. > > > > Hi Alejandro, > > > > > > Hi Ferruh, > > > > > > Getting a few build errors, more details below. > > > > > > > > Signed-off-by: Alejandro Lucero > > > > <...> > > > > > + /* Obtain target's CPP ID and offset in target */ > > > + cpp_id =3D (offset >> 40) << 8; > > > > With icc, i686 getting [1], it seems 'off_t' is 32bits long on 32bi= t > build. > > > > [1] > > error #63: shift count is too large > > > > > > We do not support 32 bits. I thought our PMD was not built in that case= . > > If PMD doesn't support 32 bits, above is OK, I will update my script > accordingly. > > > > > > > <...> > > > > > + if (err !=3D (int)len) { > > > + printf("%s: error when receiving, %= d > of %lu\n", > > > + __func__, err, count); > > > > Giving build error for 32bits [3], and can you please use logging > macros instead > > of printf? > > > > > > Sure. > > > > > > [3] > > error: format =E2=80=98%lu=E2=80=99 expects argument of type =E2=80= =98long unsigned int=E2=80=99, > but argument 4 > > has type =E2=80=98size_t=E2=80=99 {aka =E2=80=98unsigned int=E2=80= =99} [-Werror=3Dformat=3D] > > > > <...> > > > > > + /* Obtain target's CPP ID and offset in target */ > > > + cpp_id =3D (offset >> 40) << 8; > > > > Same as above [1]. > > > > <...> > > > > > + if (err !=3D (int)len) { > > > + printf("%s: error when sending: %d > of %lu\n", > > > + __func__, err, count); > > > > Same build error with above [3]. > > > > <...> > > > > > +nfp_cpp_bridge_serve_ioctl(int sockfd, struct nfp_cpp *cpp) > > > +{ > > > + int cmd, err; > > > + uint32_t ident_size, tmp; > > > + > > > + /* Reading now the IOCTL command */ > > > + err =3D recv(sockfd, &cmd, 4, 0); > > > + if (err !=3D 4) { > > > + printf("%s: read error from socket\n", __func__); > > > + return -EIO; > > > + } > > > + > > > + /* Only supporting NFP_IOCTL_CPP_IDENTIFICATION */ > > > + if (cmd !=3D NFP_IOCTL_CPP_IDENTIFICATION) { > > > > Giving build error with ppc_64-power8-linuxapp-gcc [2]. > > > > > > We do not support power architecture. > > Yes but issue seems not exactly ppc issue, more like signed - unsigned > comparison. Can you please check if is there any valid issue here? > > This is a funny one. NFP_IOCTL_CPP_IDENTIFICATION is not zero, and cmd could be anything. And it does work with other compilers! Talking with a compiler guy in the office, and it is hard to know why the compiler is triggering an error here. I suspect this is some sort of endianness mess, and he thinks the compiler could be assuming the cmd variable after recv call is always negative or positive, and the macro always being the opposite in powerpc, so the comparison is always true, what is what the error message says. Anyway, it is not clear how to fix this. Maybe defining cmd as uint32_t could help. Any change we can test this before sending another patch version? > > > > > > [2] > > error: comparison is always true due to limited range of data type > > [-Werror=3Dtype-limits] > > > >