From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id 6CE361B43B for ; Wed, 9 Jan 2019 15:20:50 +0100 (CET) Received: by mail-io1-f68.google.com with SMTP id k2so6111485iog.7 for ; Wed, 09 Jan 2019 06:20:50 -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=QDS4C0Yd+v0wp8cg0dgkIQ5MkzyQWX0AZyZKZwbce58=; b=gQIuEVH22sKS3UKxCJ3TF2Dm89ilz7uwRs2lPXjf6T6cq0G52Af3+wv7FpfLBWo0ya nBpLlHfH2tIhXL+TqUmVCqZWT5+L6EA/5wgUuTR8pP87Fc/Ysb2m98s1Sf7VNgBaUA3Y uy7ZJ21f+CFLh3gu7firptReAw7BM+GaMm8WSoanp9CV5acZiNMh5pig4dXTEtDcyrga CVgp/2d/+ofbQoG+ai4WgDiLxDxJ2/2Y/GL1xk97eeni2Rj1Xg4rTXD8Xasp7USjZykz RJkue6GxsSCoQiAWbA9kN7Nr5pm9pMrvy4Qht4tAKlZNPQTfC2htrq2B6C3/jQV3m0P9 VZXA== 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=QDS4C0Yd+v0wp8cg0dgkIQ5MkzyQWX0AZyZKZwbce58=; b=T8nvPlR+b7H0EUMnUKMCdRKzUFlhui8eOkgl0tR2Bfg1WUFX1lS6eW5tbfIIrR4TbE Hesi16Lm6WhndaGyQ5lSPsrIp+/fjrkCQdk7AVB47uIDmmtTpRHhQKZQhRHyXoTgxPlp ryPSdMdDzw/OqecjByE+rk/hofz3lp7h3pfJI91Ddd9qNPM8k6PgOpyMoZ20Zzr8FURY s//kbcmqBEGuB955qD/YuuFhZkBLbyiFM5/JDGg5JZ8UjwK2mHyeNURdU0c/LNC2uQGO VwGkPMvh2CjlYLQTaPA4IRcjW7rEHpIJBwBEV8nEy3qtUNBbkJPaNuoXBEjd9deSFDPt EEmA== X-Gm-Message-State: AJcUukecnuOtI+rtbhOTYYyrz03uwJEagVkXIs3oWM0ltFBs81jqiuWO dCciaWAlt2I1PujE0TKZvtRAZiJgri603j3GhiNjaA== X-Google-Smtp-Source: ALg8bN64ZQzmi1bmp1IQqdg0IUXcQXh69FPLv6UO6/RELeHtrr7Ny3mIuHv9ZuOEyDrV64KzT956QZuks4nTMbyBy7k= X-Received: by 2002:a5d:844d:: with SMTP id w13mr3648013ior.17.1547043649775; Wed, 09 Jan 2019 06:20:49 -0800 (PST) MIME-Version: 1.0 References: <20190103085621.23611-1-alejandro.lucero@netronome.com> <09fd5132-905b-bbe0-1178-392595027353@intel.com> In-Reply-To: <09fd5132-905b-bbe0-1178-392595027353@intel.com> From: Alejandro Lucero Date: Wed, 9 Jan 2019 14:20:38 +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: Wed, 09 Jan 2019 14:20:50 -0000 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 programmable > > with the goal of processing packets at high speed. Processing units > > 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 componen= t. > > > > There exist NFP host tools which access the NFP components for > > programming and debugging but they require the CPP interface. When 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 and > > 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 32bit buil= d. > > [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 (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=98lon= g 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. > [2] > error: comparison is always true due to limited range of data type > [-Werror=3Dtype-limits] >