All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Alejandro Lucero <alejandro.lucero@netronome.com>
Cc: dev <dev@dpdk.org>
Subject: Re: [PATCH] net/nfp: add CPP bridge as service
Date: Wed, 9 Jan 2019 16:15:10 +0000	[thread overview]
Message-ID: <9afed691-6710-7efd-09e7-ae927cc091a8@intel.com> (raw)
In-Reply-To: <CAD+H992A_AEoF3oy3Um3_rQnLTMMOmy9m-9uiiBHQjZ84_xkrA@mail.gmail.com>

On 1/9/2019 2:20 PM, Alejandro Lucero wrote:
> 
> 
> On Wed, Jan 9, 2019 at 10:54 AM Ferruh Yigit <ferruh.yigit@intel.com
> <mailto:ferruh.yigit@intel.com>> 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 component.
>     >
>     > 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 <alejandro.lucero@netronome.com
>     <mailto:alejandro.lucero@netronome.com>>
>     <...>
> 
>     > +     /* Obtain target's CPP ID and offset in target */
>     > +     cpp_id = (offset >> 40) << 8;
> 
>     With icc, i686 getting [1], it seems 'off_t' is 32bits long on 32bit 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 != (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 ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4
>     has type ‘size_t’ {aka ‘unsigned int’} [-Werror=format=] 
> 
>     <...>
> 
>     > +     /* Obtain target's CPP ID and offset in target */
>     > +     cpp_id = (offset >> 40) << 8;
> 
>     Same as above [1].
> 
>     <...>
> 
>     > +                     if (err != (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 = recv(sockfd, &cmd, 4, 0);
>     > +     if (err != 4) {
>     > +             printf("%s: read error from socket\n", __func__);
>     > +             return -EIO;
>     > +     }
>     > +
>     > +     /* Only supporting NFP_IOCTL_CPP_IDENTIFICATION */
>     > +     if (cmd != 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?

>  
> 
>     [2]
>     error: comparison is always true due to limited range of data type
>     [-Werror=type-limits]
> 

  reply	other threads:[~2019-01-09 16:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-03  8:56 [PATCH] net/nfp: add CPP bridge as service Alejandro Lucero
2019-01-09 10:54 ` Ferruh Yigit
2019-01-09 14:20   ` Alejandro Lucero
2019-01-09 16:15     ` Ferruh Yigit [this message]
2019-01-10 11:55       ` Alejandro Lucero
2019-01-11 11:48         ` Ferruh Yigit
2019-01-11 12:15           ` Alejandro Lucero
2019-01-11 12:35             ` Ferruh Yigit
2019-01-11 13:25 Alejandro Lucero
2019-01-11 16:42 ` Ferruh Yigit
2019-01-13 21:41   ` Thomas Monjalon
2019-01-14 10:40     ` Ferruh Yigit
2019-01-14 18:00       ` Alejandro Lucero
2019-01-14 18:22         ` Ferruh Yigit
2019-01-14 18:29           ` Alejandro Lucero
2019-01-14 18:54             ` Thomas Monjalon
2019-01-14 19:26               ` Alejandro Lucero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9afed691-6710-7efd-09e7-ae927cc091a8@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=alejandro.lucero@netronome.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.