Re: [dpdk-dev] [PATCH 2/2] hyperv: VMBUS support infrastucture

[Thomas Monjalon]

2016-12-16 12:15, Stephen Hemminger:
> On Fri, 16 Dec 2016 19:09:02 +0100
> Thomas Monjalon  wrote:
> 
> > 2016-12-15 09:26, Stephen Hemminger:
> > > On Thu, 15 Dec 2016 12:19:44 +0530
> > > Shreyansh Jain  wrote:  
> > > > It is not a scale-able model where we have to change eth_driver/eth_dev 
> > > > for every new device type, other than PCI. Maybe VMBus is _very_ close 
> > > > to PCI so no changes are required in PCI layer (common, linuxapp, 
> > > > bsdapp) - but, for others it won't stop there.
> > > > 
> > > > At the least, rte_pci_driver/rte_pci_device should be removed from 
> > > > eth_driver & rte_eth_dev, respectively - relying on rte_driver and 
> > > > rte_device.
> > > > 
> > > > This is the primary reason work on the SoC patchset and now the new Bus 
> > > > model is being done.  
> > > 
> > > Agreed. the better long term model is to use C style inheritance where
> > > rte_pci_driver has eth_driver inside. 
> > > The other alternative is to make the second element an opaque pointer.
> > > 
> > > But that was too big a change, and not necessary to get VMBUS to work.
> > > Longer term refactoring will take more effort. Go ahead and address it
> > > with a better bus model, but that probably isn't going to be ready for
> > > a couple of releases.  
> > 
> > We'll consider only the approach of generalizing the bus model for integr   
> > ation.
> > Stephen, you are welcome to help make it happen and rebase your work
> > on top of this new model.
> > Thanks
> 
> I will generalize it to PCI and VMBUS only. I am not inventing a generic SOC
> model since that is something that I don't have sufficient knowledge. This
> fits the YAGNI principle. 

There is already a work in progress to generalize bus handling. It is not
specific to SoC design. It is just a better design to add new buses.

Re: [dpdk-dev] [PATCH 02/32] drivers/common: introducing dpaa2 mc driver

[Jerin Jacob]

On Sun, Dec 04, 2016 at 11:46:57PM +0530, Hemant Agrawal wrote:
> This patch intoduces the DPAA2 MC(Management complex Driver)
> 
> This driver is common to be used by various DPAA2 net, crypto
> and other drivers
> 
> Signed-off-by: Cristian Sovaiala 
> [Hemant:rebase and conversion to library for DPDK]
> Signed-off-by: Hemant Agrawal 
>  
>  include $(RTE_SDK)/mk/rte.vars.mk
>  
> +DIRS-y += common
>  DIRS-y += net
>  DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto
>  
> diff --git a/drivers/common/Makefile b/drivers/common/Makefile
> new file mode 100644
> index 000..0c3f35f
> --- /dev/null
> +++ b/drivers/common/Makefile
> @@ -0,0 +1,36 @@
> +#   BSD LICENSE
> +#
> +#   Copyright(c) 2016 NXP. All rights reserved.
> +#   All rights reserved.
> +#
> +#   Redistribution and use in source and binary forms, with or without
> +#   modification, are permitted provided that the following conditions
> +#   are met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +#   notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above copyright
> +#   notice, this list of conditions and the following disclaimer in
> +#   the documentation and/or other materials provided with the
> +#   distribution.
> +# * Neither the name of NXP nor the names of its
> +#   contributors may be used to endorse or promote products derived
> +#   from this software without specific prior written permission.
> +#
> +#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> +#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> +#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> +#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> +#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> +#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> +#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +DIRS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) += dpaa2

If you are planning to build "external pool" driver or "eventdev" driver or net
pmd driver as stand alone build then you could try generating the config for
common code by selection of "external pool" or "eventdev" or net-pmd driver.
something like below

CONFIG_RTE_LIBRTE_OCTEONTX_COMMON = $(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF)
ifneq ($(CONFIG_RTE_LIBRTE_OCTEONTX_COMMON),y)
CONFIG_RTE_LIBRTE_OCTEONTX_COMMON =
$(CONFIG_RTE_LIBRTE_MEMPOOL_OCTEONTX_FPAVF)
endif
ifneq ($(CONFIG_RTE_LIBRTE_OCTEONTX_COMMON),y)
CONFIG_RTE_LIBRTE_OCTEONTX_COMMON = $(CONFIG_RTE_LIBRTE_PMD_OCTEONTX)
endif

DIRS-$(CONFIG_RTE_LIBRTE_OCTEONTX_COMMON) += octeontx

Re: [dpdk-dev] No packets received if burst is too small in rte_eth_rx_burst

[tom . barbette]

Hi,

Your comments made me saw the line "PMD: i40e_set_rx_function(): Vector rx 
enabled, please make sure RX burst size no less than 4 (port=0)."

The problem was probably that I was under this limit... Is there a way to get 
that limit through a function or something? 

With 16.04 I received sometimes 5 or 7 packets with a burst_size of 4 which 
respects this limit. I see that "[dpdk-dev] net/i40e: fix out-of-bounds writes 
during vector Rx" fixed that, as the limit was in fact 32 no matter the message.

At the end, what should be the minimal rx burst size? How to find it at runtime 
for any NIC? I imagine that vector rx will create a problem if I give a burst 
size of 1 even with a recent DPDK version, right?

Thanks,
Tom

Tom Barbette 
PhD Student @ Université de Liège 

Office 1/13 
Bâtiment B37 
Quartier Polytech 
Allée de la découverte, 12 
4000 Liège 

04/366 91 75 
0479/60 94 63 


- Mail original -
De: "Bruce Richardson" 
À: "tom barbette" 
Cc: dev@dpdk.org
Envoyé: Mercredi 14 Décembre 2016 17:52:21
Objet: Re: [dpdk-dev] No packets received if burst is too small in 
rte_eth_rx_burst

On Wed, Dec 14, 2016 at 04:13:53PM +0100, tom.barbe...@ulg.ac.be wrote:
> Hi list,
> 
> Between 2.2.0 and 16.04 (up to at least 16.07.2 if not current), with the 
> XL710 controller I do not get any packet when calling rte_eth_rx_burst if 
> nb_pkts is too small. I would say smaller than 32. The input rate is not big, 
> if that helps. But It should definitely get at least one packet per second.
> 
> Any ideas? Is that a bug or expected behaviour? Could be caused by other ABI 
> changes?
> 
Does this issue still occur even if you disable the vector driver in
your build-time configuration?

/Bruce

Re: [dpdk-dev] [PATCH 29/29] net/ixgbe/base: update version of basical codes in README

[Dai, Wei]

Thanks to Yigit Ferruh.

> -Original Message-
> From: Yigit, Ferruh
> Sent: Tuesday, December 6, 2016 3:41 AM
> To: Dai, Wei ; Zhang, Helin ;
> Ananyev, Konstantin 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 29/29] net/ixgbe/base: update version of 
> basical
> codes in README
> 
> On 12/4/2016 6:31 AM, Wei Dai wrote:
> > update the version of shared codes to cid-ixgbe.2016.11.21.tar.gz, all
> > files in net/ixgbe/base are developped by another team and DPDK PMD
> > uses them accordingly.
> >
> > Signed-off-by: Wei Dai 
> > ---
> >  drivers/net/ixgbe/base/README | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ixgbe/base/README
> > b/drivers/net/ixgbe/base/README index 6b54c31..84773ff 100644
> > --- a/drivers/net/ixgbe/base/README
> > +++ b/drivers/net/ixgbe/base/README
> > @@ -34,7 +34,8 @@ Intel® IXGBE driver
> >  ===
> >
> >  This directory contains source code of FreeBSD ixgbe driver of
> > version
> > -cid-10g-shared-code.2016.08.15 released by ND. The sub-directory of
> > base/
> > +cid-10g-shared-code.2016.08.15 released by the team which develop
> 
> I guess version needs to be updated to 2016.11.21 ?
Yes, it should be updated to 2016.11.21 .
> 
> > +basical drivers for any ixgbe NIC. The sub-directory of base/
> >  contains the original source package.
> >  This driver is valid for the product(s) listed below
> >
> >

[dpdk-dev] implementing flex filters using wake-up packets

[Cody Doucette]

Looking at the e1000 driver, it seems like the flexible filter type
(RTE_ETH_FILTER_FLEXIBLE) is implemented using wake-up filters.

If that's correct, is it possible to take the same approach for ixgbe? I'm
using an 82599 (which has flexible wake-up filters), and I'd like to try to
implement RTE_ETH_FILTER_FLEXIBLE for ixgbe to match something like an IPv6
Neighbor Discovery packet.

Any thoughts on whether this is possible or tips on how to do it would be
appreciated. Thanks!

Cody

[dpdk-dev] [PATCH] net/af_packet: initialize link interrupt callback queue

[Chas Williams]

This patch initializes the eth_dev->link_intr_cbs queue which is
used when af_packet is passed into rte_eth_ev_callback_register().

Fixes: 4dc294158cac ("ethdev: support optional Rx and Tx callbacks")

Signed-off-by: Chas Williams <3ch...@gmail.com>
---
 drivers/net/af_packet/rte_eth_af_packet.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index a1e13ff..ea5070a 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -708,6 +708,7 @@ rte_pmd_init_internals(const char *name,
(*eth_dev)->data->drv_name = pmd_af_packet_drv.driver.name;
(*eth_dev)->data->kdrv = RTE_KDRV_NONE;
(*eth_dev)->data->numa_node = numa_node;
+   TAILQ_INIT(&((*eth_dev)->link_intr_cbs));
 
return 0;
 
-- 
2.7.4

Re: [dpdk-dev] ConnectX4 100GbE - Compilation problem

[Olga Shern]

Hi Georgios,

Did you install MLNX_OFED?
You probably missing libmlx5-devel package

Best Regards,
Olga

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of george@gmail.com
Sent: Friday, December 16, 2016 4:46 PM
To: Georgios Katsikas ; dev@dpdk.org
Subject: Re: [dpdk-dev] ConnectX4 100GbE - Compilation problem

Hi all,

I am coming back to you regarding the Mellanox Connectx4 100Gbps DPDK driver.
We exchanged some e-mails last summer and I managed to compile the DPDK-based 
Mellanox driver using DPDK 16.07 on top of Ubuntu server 16.04.01.

A few days ago, I installed a fresh Ubuntu server 16.04.1 on my machine and 
attempted to re-install DPDK.
This time, DPDK does not compile because of the following error:
\== Build drivers/net/mlx5
  CC mlx5.o
In file included from /opt/dpdk/drivers/net/mlx5/mlx5.h:67:0,
 from /opt/dpdk/drivers/net/mlx5/mlx5.c:66:
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.h:46:32: fatal error:
infiniband/mlx5_hw.h: No such file or directory compilation terminated.
/opt/dpdk/mk/internal/rte.compile-pre.mk:138: recipe for target 'mlx5.o'
failed
make[6]: *** [mlx5.o] Error 1
/opt/dpdk/mk/rte.subdir.mk:61: recipe for target 'mlx5' failed
make[5]: *** [mlx5] Error 2
/opt/dpdk/mk/rte.subdir.mk:61: recipe for target 'net' failed
make[4]: *** [net] Error 2
/opt/dpdk/mk/rte.sdkbuild.mk:78: recipe for target 'drivers' failed
make[3]: *** [drivers] Error 2
/opt/dpdk/mk/rte.sdkroot.mk:126: recipe for target 'all' failed
make[2]: *** [all] Error 2
/opt/dpdk/mk/rte.sdkinstall.mk:85: recipe for target 'pre_install' failed
make[1]: *** [pre_install] Error 2
/opt/dpdk/mk/rte.sdkroot.mk:101: recipe for target 'install' failed
make: *** [install] Error 2
[ ERROR] [  CheckStatus] Command make install failed

I tried 2 different kernels (4.4 and 4.8) both compiled from sources and I also 
tried 3 different DPDk versions (16.04/07/11) but they all get stuck to this 
point.
The way I configure DPDK is via config/common_base, where I set 
CONFIG_RTE_LIBRTE_MLX5_PMD=y.
The file infiniband/mlx5_hw.h does not exist in my system although I have 
installed libmlx5.

Do you know why does this happen now?

Thanks in advance and best regards,
Georgios

On Thu, Aug 18, 2016 at 7:35 PM,  wrote:

> Hi Adrien,
>
> Thanks for the prompt reply!
> You are right, I didn't go via the DPDK route, in the hope that 
> Mellanox will provide the exact source and configuration.
> DPDK 16.07 from dpdk.org works like a charm and my NIC is in PMD mode, 
> thanks a lot for your guidance!
>
> Best regards,
> Georgios
>
> On Thu, Aug 18, 2016 at 6:05 PM, Adrien Mazarguil < 
> adrien.mazarg...@6wind.com> wrote:
>
>> Hi George,
>>
>> On Thu, Aug 18, 2016 at 05:41:38PM +0200, george@gmail.com wrote:
>> > Hi,
>> >
>> > I have a single port Mellanox ConnectX 4 100GbE NIC and I want to 
>> > test
>> its
>> > Rx/Tx capabilites  using DPDK.
>> > My system runs a Linux kernel 4.4 compiled from sources.
>> >
>> > I found the PMD driver for this NIC as provided by Mellanox here
>> > > 9&mtag=pmd_for_dpdk>
>> > .
>> > Following this
>> > > DPDK_Quick_Start_Guide_v2.2_2.7.pdf>
>> > guideline, I put my NIC in Ethernet mode, configured the 3 options 
>> > regarding mlx5 in the config/common_linuxapp file and applied 'make
>> install
>> > T=x86_64-native-linuxapp-gcc'.
>>
>> Please note this is a third party package maintained by Mellanox, 
>> therefore this mailing list is not the right place to discuss related 
>> errors, unless they can be reproduced with a version downloaded from 
>> dpdk.org.
>>
>> > Then, I stumbled upon a compilation problem in the mlx4 module.
>> > The compiler's output is as follows:
>> >
>> > == Build drivers/net/mlx4
>> >   CC mlx4.o
>> > In file included from /usr/include/linux/if.h:31:0,
>> >  from /opt/MLNX_DPDK_2.2_2.7/drivers
>> /net/mlx4/mlx4.c:57:
>> > /usr/include/linux/hdlc/ioctl.h:73:14: error: ‘IFNAMSIZ’ undeclared
>> here
>> > (not in a function)
>> >   char master[IFNAMSIZ]; /* Name of master FRAD device */
>> >   ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:612:53: error: 
>> > ‘struct ifreq’ declared inside parameter list [-Werror]  
>> > priv_ifreq(const struct priv *priv, int req, struct ifreq *ifr)
>> >  ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:612:53: error: its
>> scope is
>> > only this definition or declaration, which is probably not what you 
>> > want [-Werror]
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c: In function
>> ‘priv_ifreq’:
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:619:32: error:
>> dereferencing
>> > pointer to incomplete type ‘struct ifreq’
>> >   if (priv_get_ifname(priv, &ifr->ifr_name) == 0)
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c: In function
>> ‘r

Re: [dpdk-dev] [PATCH v2 00/25] Generic flow API (rte_flow)

[Olga Shern]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Adrien Mazarguil
> Sent: Friday, December 16, 2016 6:25 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2 00/25] Generic flow API (rte_flow)
> 
> As previously discussed in RFC v1 [1], RFC v2 [2], with changes described in
> [3] (also pasted below), here is the first non-draft series for this new API.
> 
> Its capabilities are so generic that its name had to be vague, it may be 
> called
> "Generic flow API", "Generic flow interface" (possibly shortened as "GFI") to
> refer to the name of the new filter type, or "rte_flow" from the prefix used
> for its public symbols. I personally favor the latter.
> 
> While it is currently meant to supersede existing filter types in order for 
> all
> PMDs to expose a common filtering/classification interface, it may eventually
> evolve to cover the following ideas as well:
> 
> - Rx/Tx offloads configuration through automatic offloads for specific
>   packets, e.g. performing checksum on TCP packets could be expressed with
>   an egress rule with a TCP pattern and a kind of checksum action.
> 
> - RSS configuration (already defined actually). Could be global or per rule
>   depending on hardware capabilities.
> 
> - Switching configuration for devices with many physical ports; rules doing
>   both ingress and egress could even be used to completely bypass software
>   if supported by hardware.
> 
>  [1] http://dpdk.org/ml/archives/dev/2016-July/043365.html
>  [2] http://dpdk.org/ml/archives/dev/2016-August/045383.html
>  [3] http://dpdk.org/ml/archives/dev/2016-November/050044.html
> 
> Changes since v1 series:
> 
> - Added programmer's guide documentation for rte_flow.
> 
> - Added depreciation notice for the legacy API.
> 
> - Documented testpmd flow command.
> 
> - Fixed missing rte_flow_flush symbol in rte_ether_version.map.
> 
> - Cleaned up API documentation in rte_flow.h.
> 
> - Replaced "min/max" parameters with "num" in struct rte_flow_item_any,
> to
>   align behavior with other item definitions.
> 
> - Fixed "type" (EtherType) size in struct rte_flow_item_eth.
> 
> - Renamed "queues" to "num" in struct rte_flow_action_rss.
> 
> - Fixed missing const in rte_flow_error_set() prototype definition.
> 
> - Fixed testpmd flow create command that did not save the rte_flow object
>   pointer, causing crashes.
> 
> - Hopefully fixed all the remaining ICC/clang errors.
> 
> - Replaced testpmd flow command's "fix" token with "is" for clarity.
> 
> Changes since RFC v2:
> 
> - New separate VLAN pattern item (previously part of the ETH definition),
>   found to be much more convenient.
> 
> - Removed useless "any" field from VF pattern item, the same effect can be
>   achieved by not providing a specification structure.
> 
> - Replaced bit-fields from the VXLAN pattern item to avoid endianness
>   conversion issues on 24-bit fields.
> 
> - Updated struct rte_flow_item with a new "last" field to create inclusive
>   ranges. They are defined as the interval between (spec & mask) and
>   (last & mask). All three parameters are optional.
> 
> - Renamed ID action MARK.
> 
> - Renamed "queue" fields in actions QUEUE and DUP to "index".
> 
> - "rss_conf" field in RSS action is now const.
> 
> - VF action now uses a 32 bit ID like its pattern item counterpart.
> 
> - Removed redundant struct rte_flow_pattern, API functions now expect
>   struct
>   rte_flow_item lists terminated by END items.
> 
> - Replaced struct rte_flow_actions for the same reason, with struct
>   rte_flow_action lists terminated by END actions.
> 
> - Error types (enum rte_flow_error_type) have been updated and the cause
>   pointer in struct rte_flow_error is now const.
> 
> - Function prototypes (rte_flow_create, rte_flow_validate) have also been
>   updated for clarity.
> 
> Additions:
> 
> - Public wrapper functions rte_flow_{validate|create|destroy|flush|query}
>   are now implemented in rte_flow.c, with their symbols exported and
>   versioned. Related filter type RTE_ETH_FILTER_GENERIC has been added.
> 
> - A separate header (rte_flow_driver.h) has been added for driver-side
>   functionality, in particular struct rte_flow_ops which contains PMD
>   callbacks returned by RTE_ETH_FILTER_GENERIC query.
> 
> - testpmd now exposes most of this API through the new "flow" command.
> 
> What remains to be done:
> 
> - Using endian-aware integer types (rte_beX_t) where necessary for clarity.
> 
> - API documentation (based on RFC).
> 
> - testpmd flow command documentation (although context-aware command
>   completion should already help quite a bit in this regard).
> 
> - A few pattern item / action properties cannot be configured yet
>   (e.g. rss_conf parameter for RSS action) and a few completions
>   (e.g. possible queue IDs) should be added.
> 

Acked-by: Olga Shern 

Re: [dpdk-dev] [PATCH] net/af_packet: initialize link interrupt callback queue

[Stephen Hemminger]

On Sat, 17 Dec 2016 13:03:55 -0500
Chas Williams <3ch...@gmail.com> wrote:

> This patch initializes the eth_dev->link_intr_cbs queue which is
> used when af_packet is passed into rte_eth_ev_callback_register().
> 
> Fixes: 4dc294158cac ("ethdev: support optional Rx and Tx callbacks")
> 
> Signed-off-by: Chas Williams <3ch...@gmail.com>
> ---
>  drivers/net/af_packet/rte_eth_af_packet.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
> b/drivers/net/af_packet/rte_eth_af_packet.c
> index a1e13ff..ea5070a 100644
> --- a/drivers/net/af_packet/rte_eth_af_packet.c
> +++ b/drivers/net/af_packet/rte_eth_af_packet.c
> @@ -708,6 +708,7 @@ rte_pmd_init_internals(const char *name,
>   (*eth_dev)->data->drv_name = pmd_af_packet_drv.driver.name;
>   (*eth_dev)->data->kdrv = RTE_KDRV_NONE;
>   (*eth_dev)->data->numa_node = numa_node;
> + TAILQ_INIT(&((*eth_dev)->link_intr_cbs));

This code really needs to have a local variable for eth_dev and not deref
a pointer in every statement.

Re: [dpdk-dev] ConnectX4 100GbE - Compilation problem

[george . dit]

Hi Olga,

That was the issue indeed, thank you very much!

Best regards,
Georgios

On Sat, Dec 17, 2016 at 10:26 PM, Olga Shern  wrote:

> Hi Georgios,
>
> Did you install MLNX_OFED?
> You probably missing libmlx5-devel package
>
> Best Regards,
> Olga
>
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of george@gmail.com
> Sent: Friday, December 16, 2016 4:46 PM
> To: Georgios Katsikas ; dev@dpdk.org
> Subject: Re: [dpdk-dev] ConnectX4 100GbE - Compilation problem
>
> Hi all,
>
> I am coming back to you regarding the Mellanox Connectx4 100Gbps DPDK
> driver.
> We exchanged some e-mails last summer and I managed to compile the
> DPDK-based Mellanox driver using DPDK 16.07 on top of Ubuntu server
> 16.04.01.
>
> A few days ago, I installed a fresh Ubuntu server 16.04.1 on my machine
> and attempted to re-install DPDK.
> This time, DPDK does not compile because of the following error:
> \== Build drivers/net/mlx5
>   CC mlx5.o
> In file included from /opt/dpdk/drivers/net/mlx5/mlx5.h:67:0,
>  from /opt/dpdk/drivers/net/mlx5/mlx5.c:66:
> /opt/dpdk/drivers/net/mlx5/mlx5_rxtx.h:46:32: fatal error:
> infiniband/mlx5_hw.h: No such file or directory compilation terminated.
> /opt/dpdk/mk/internal/rte.compile-pre.mk:138: recipe for target 'mlx5.o'
> failed
> make[6]: *** [mlx5.o] Error 1
> /opt/dpdk/mk/rte.subdir.mk:61: recipe for target 'mlx5' failed
> make[5]: *** [mlx5] Error 2
> /opt/dpdk/mk/rte.subdir.mk:61: recipe for target 'net' failed
> make[4]: *** [net] Error 2
> /opt/dpdk/mk/rte.sdkbuild.mk:78: recipe for target 'drivers' failed
> make[3]: *** [drivers] Error 2
> /opt/dpdk/mk/rte.sdkroot.mk:126: recipe for target 'all' failed
> make[2]: *** [all] Error 2
> /opt/dpdk/mk/rte.sdkinstall.mk:85: recipe for target 'pre_install' failed
> make[1]: *** [pre_install] Error 2
> /opt/dpdk/mk/rte.sdkroot.mk:101: recipe for target 'install' failed
> make: *** [install] Error 2
> [ ERROR] [  CheckStatus] Command make install failed
>
> I tried 2 different kernels (4.4 and 4.8) both compiled from sources and I
> also tried 3 different DPDk versions (16.04/07/11) but they all get stuck
> to this point.
> The way I configure DPDK is via config/common_base, where I set
> CONFIG_RTE_LIBRTE_MLX5_PMD=y.
> The file infiniband/mlx5_hw.h does not exist in my system although I have
> installed libmlx5.
>
> Do you know why does this happen now?
>
> Thanks in advance and best regards,
> Georgios
>
> On Thu, Aug 18, 2016 at 7:35 PM,  wrote:
>
> > Hi Adrien,
> >
> > Thanks for the prompt reply!
> > You are right, I didn't go via the DPDK route, in the hope that
> > Mellanox will provide the exact source and configuration.
> > DPDK 16.07 from dpdk.org works like a charm and my NIC is in PMD mode,
> > thanks a lot for your guidance!
> >
> > Best regards,
> > Georgios
> >
> > On Thu, Aug 18, 2016 at 6:05 PM, Adrien Mazarguil <
> > adrien.mazarg...@6wind.com> wrote:
> >
> >> Hi George,
> >>
> >> On Thu, Aug 18, 2016 at 05:41:38PM +0200, george@gmail.com wrote:
> >> > Hi,
> >> >
> >> > I have a single port Mellanox ConnectX 4 100GbE NIC and I want to
> >> > test
> >> its
> >> > Rx/Tx capabilites  using DPDK.
> >> > My system runs a Linux kernel 4.4 compiled from sources.
> >> >
> >> > I found the PMD driver for this NIC as provided by Mellanox here
> >> >  >> 9&mtag=pmd_for_dpdk>
> >> > .
> >> > Following this
> >> >  >> DPDK_Quick_Start_Guide_v2.2_2.7.pdf>
> >> > guideline, I put my NIC in Ethernet mode, configured the 3 options
> >> > regarding mlx5 in the config/common_linuxapp file and applied 'make
> >> install
> >> > T=x86_64-native-linuxapp-gcc'.
> >>
> >> Please note this is a third party package maintained by Mellanox,
> >> therefore this mailing list is not the right place to discuss related
> >> errors, unless they can be reproduced with a version downloaded from
> >> dpdk.org.
> >>
> >> > Then, I stumbled upon a compilation problem in the mlx4 module.
> >> > The compiler's output is as follows:
> >> >
> >> > == Build drivers/net/mlx4
> >> >   CC mlx4.o
> >> > In file included from /usr/include/linux/if.h:31:0,
> >> >  from /opt/MLNX_DPDK_2.2_2.7/drivers
> >> /net/mlx4/mlx4.c:57:
> >> > /usr/include/linux/hdlc/ioctl.h:73:14: error: ‘IFNAMSIZ’ undeclared
> >> here
> >> > (not in a function)
> >> >   char master[IFNAMSIZ]; /* Name of master FRAD device */
> >> >   ^
> >> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:612:53: error:
> >> > ‘struct ifreq’ declared inside parameter list [-Werror]
> >> > priv_ifreq(const struct priv *priv, int req, struct ifreq *ifr)
> >> >  ^
> >> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:612:53: error: its
> >> scope is
> >> > only this definition or declaration, which is probably not what you
> >> > want [-Werror]
> >> > /opt/MLNX_