[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT

[Olga Shern]

Hi Tim, 

Can you please send the presentations from last Community Call.
We have Tetsuya's presentation,  if we can also get other presentations it will 
be great

Thanks
Olga


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
> Sent: Tuesday, December 02, 2014 4:41 AM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00
> AM GMT
> 
> Hi Folks,
> 
> I attached slides that describe current progress of port hotplug feature.
> 
> Regards,
> Tetsuya
> 
> (2014/12/01 18:40), O'driscoll, Tim wrote:
> > Hi Tetsuya,
> >
> > It would be great if you could explain your work on hotplug at tomorrow's
> call. I think this is a topic that lots of people will be interested in.
> >
> > I'm not sure of the policy for sending attachments to the list. Perhaps 
> > that's
> something that Thomas can clarify. Can you send the slides to me anyway,
> just in case there's any problem with you presenting them in GoToMeeting
> tomorrow. I will also record the session and post the video for those who
> can't attend.
> >
> >
> > Tim
> >
> >> -Original Message-
> >> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> >> Sent: Monday, December 1, 2014 2:50 AM
> >> To: O'driscoll, Tim; dev at dpdk.org
> >> Subject: Re: [dpdk-dev] Next Community Call, Tuesday 2nd December,
> >> 8:00 AM GMT
> >>
> >> Hi Tim,
> >>
> >> Could I explain port hotplug function at next conference call?
> >> For this explanation, I've prepared slides. could I send a PDF to this ML?
> >> That slides describe what is the function, how it works and what is
> >> current progress.
> >> And it's under 100KB.
> >>
> >> Regards,
> >> Tetsuya
> >>
> >> (2014/11/22 1:08), O'driscoll, Tim wrote:
> >>> We're going to hold our next community call on Tuesday 2nd December.
> >> This time, we're going to try a time that's more suitable for
> >> participants in Asia, so we're going to hold it at 8:00 AM GMT. The
> >> meeting time in a variety of timezones is included below.
> >>> Generally, GoToMeeting worked well last time, although there was a
> >> limitation that Neil was unable to present slides as he joined from a
> >> Linux system. We'll stick with GoToMeeting again this time as we
> >> don't yet have a better solution. Details for joining the GoToMeeting
> >> session are included below.
> >>> I'll record the session again and post the video to YouTube
> >>> afterwards for
> >> anybody who can't make it. This seemed to work well last time, and as
> >> Kevin pointed out, the audio quality on the recording is good.
> >>> For the agenda, we'd like to discuss the following:
> >>> ? Remaining 2.0 candidate features, especially PCI Hotplug as
> >>> there's been a
> >> lot of discussion on that on the mailing list. Hopefully Tetsuya
> >> Mukawa can join us to describe his work on this.
> >>> ? DPDK Test Suite. We hope to announce the release of this next week.
> >> Waterman Cao and Yong (Marvin) Liu from our Shanghai team will
> >> describe the functionality and benefits of this.
> >>>
> >>> Meeting Time:
> >>> Dublin (Ireland) Tuesday, December 2, 2014 at 8:00:00 AM GMT UTC
> >>> Paris (France) Tuesday, December 2, 2014 at 9:00:00 AM CET UTC+1
> >>> hour Tel Aviv (Israel) Tuesday, December 2, 2014 at 10:00:00 AM IST
> >>> UTC+2 hours Moscow (Russia) Tuesday, December 2, 2014 at 11:00:00
> AM
> >>> MSK UTC+3
> >> hours
> >>> New Delhi (India - Delhi) Tuesday, December 2, 2014 at 1:30:00 PM
> >>> IST
> >> UTC+5:30 hours
> >>> Shanghai (China - Shanghai Municipality) Tuesday, December 2, 2014
> >>> at
> >> 4:00:00 PM CST UTC+8 hours
> >>> Tokyo (Japan) Tuesday, December 2, 2014 at 5:00:00 PM JST UTC+9
> >>> hours San Francisco (U.S.A. - California) Midnight between Monday,
> >>> December 1,
> >> 2014 and Tuesday, December 2, 2014 PST UTC-8 hours
> >>> Phoenix (U.S.A. - Arizona) Tuesday, December 2, 2014 at 1:00:00 AM
> >>> MST
> >> UTC-7 hours
> >>> New York (U.S.A. - New York) Tuesday, December 2, 2014 at 3:00:00 AM
> >> EST UTC-5 hours
> >>> Ottawa (Canada - Ontario) Tuesday, December 2, 2014 at 3:00:00 AM
> >>> EST
> >> UTC-5 hours
> >>> Corresponding UTC (GMT) Tuesday, December 2, 2014 at 08:00:00
> >>>
> >>>
> >>> GoToMeeting Details:
> >>> To join, follow the meeting link:
> >> https://global.gotomeeting.com/join/772753069. This will start the
> >> GoToMeeting web viewer. You then have two options for audio:
> >>> 1. To use your computer's audio via a headset, you need to switch to
> >>> the
> >> desktop version of GoToMeeting. You can do this by clicking the
> >> GoToMeeting icon on the top right hand side of the web viewer, and
> >> then selecting "Switch to the desktop version". The desktop version
> >> will need to download and install, so if you plan to use this you may
> >> want to get it set up in advance. Once it starts, under the Audio
> >> section, you can select "Mic & Speakers". The desktop version is only
> >> available for Windows and Mac, so if you're using

[dpdk-dev] [PATCH] doc: update mlx4 usage and dependencies

[Olga Shern]

Hi Raghav, 

What OFED version did you install?

There are 2 ways to compile mlx4:
1. You can compile it dynamically with the libibverbs  that are coming with 
Mellanox_OFED 2.4
2. To get better performance: compile it statically with libibverbs and libmlx4 
that can be downloaded from http://dpdk.org/download, the README inside 
librte_pmd_mlx4 explains how to do it
 If you compile the pmd statically then MLNX_OFED is needed only for kernel 
modules. 

Best Regards,
Olga


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Raghav Sethi
Sent: Friday, April 03, 2015 9:21 PM
To: Adrien Mazarguil; dev at dpdk.org; Xiaozhou Li
Subject: Re: [dpdk-dev] [PATCH] doc: update mlx4 usage and dependencies

Hi Adrien,

Quick update: So I just tried the setup again on a new machine with the exact 
same hardware - installed OFED and compiled DPDK 2.0.0. Works like a charm.

Still getting the issue on the old machine (also upgraded to 2.0.0 FWIW).

[dpdk-dev] [PATCH] doc: update mlx4 usage and dependencies

[Olga Shern]

Hi Raghav,

After running /etc/init.d/openibd restart you don?t need to load the modules, 
they are loaded by the openibd script.
Can you try to run :
/etc/init.d/openibd stop
Verify that modules are not loaded
/etc/init.d/openib start

If it won?t help:
What Mellanox NIC do you have on the ?problematic? machine?
What command line do you use to run the application?

Please send output of:

1.   ?lspci | grep Mellanox?

2.   ibdev2netdev

3.   ldd 

4.   lsmod

Thanks
Olga


From: Raghav Sethi [mailto:ragh...@cs.princeton.edu]
Sent: Saturday, April 04, 2015 11:54 PM
To: Olga Shern; Adrien Mazarguil; dev at dpdk.org; Xiaozhou Li
Subject: Re: [dpdk-dev] [PATCH] doc: update mlx4 usage and dependencies

Hi Olga,

Thanks for your reply. OFED version was 2.4-1.0.4 for ubuntu14.04-x86_64

I tried both variants:
- Compiling with dynamic linking against OFED libraries
- Compiling with static linking against dpdk.org<http://dpdk.org> libraries

Both have the same issue.

Best,
Raghav

On Sat, Apr 4, 2015 at 4:49 PM Olga Shern mailto:olgas 
at mellanox.com>> wrote:
Hi Raghav,

What OFED version did you install?

There are 2 ways to compile mlx4:
1. You can compile it dynamically with the libibverbs  that are coming with 
Mellanox_OFED 2.4
2. To get better performance: compile it statically with libibverbs and libmlx4 
that can be downloaded from http://dpdk.org/download, the README inside 
librte_pmd_mlx4 explains how to do it
 If you compile the pmd statically then MLNX_OFED is needed only for kernel 
modules.

Best Regards,
Olga


-Original Message-
From: dev [mailto:dev-bounces at dpdk.org<mailto:dev-boun...@dpdk.org>] On 
Behalf Of Raghav Sethi
Sent: Friday, April 03, 2015 9:21 PM
To: Adrien Mazarguil; dev at dpdk.org<mailto:dev at dpdk.org>; Xiaozhou Li
Subject: Re: [dpdk-dev] [PATCH] doc: update mlx4 usage and dependencies

Hi Adrien,

Quick update: So I just tried the setup again on a new machine with the exact 
same hardware - installed OFED and compiled DPDK 2.0.0. Works like a charm.

Still getting the issue on the old machine (also upgraded to 2.0.0 FWIW).

[dpdk-dev] [PATCH] doc: update mlx4 usage and dependencies

[Olga Shern]

If you compiled pmd statically with libibverbs and libmlx4 you shouldn't see it 
in ldd.
Seems that something went wrong.
In any case, ofed doesn't install libraries under /usr/local
Please remove all mlx related libraries under /usr/local/ like libmlx4 and 
libibverbs





 Original message 
From: Raghav Sethi
Date:05/04/2015 00:29 (GMT+02:00)
To: Olga Shern ,Adrien Mazarguil ,dev at dpdk.org,Xiaozhou Li
Subject: Re: [dpdk-dev] [PATCH] doc: update mlx4 usage and dependencies


Hi Olga,

Thanks very much for helping.

I tried stopping and starting, after stop lsmod | grep mlx had no matches. 
After start, it had the output listed below. The device is the same as on the 
rest of the machines - Mellanox ConnectX3-EN 40G single port. The application 
parameters are the same as the ones listed on the docs (except of course PCI 
address is different):

sudo ./testpmd -c 0xff -n 4 -w :06:00.0 -- --rxq=2 --txq=2 -i

Outputs you requested:

1. lspci | grep Mellanox
06:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]

2. ibdev2netdev
mlx4_0 port 1 ==> p3p1 (Up)

3. ldd testpmd
linux-vdso.so.1 =>  (0x7fff7c1dc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f1a7dc07000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f1a7d9ff000)
libibverbs.so.1 => /usr/local/lib/libibverbs.so.1 (0x7f1a7d7eb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f1a7d5e7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f1a7d3c9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1a7d003000)
/lib64/ld-linux-x86-64.so.2 (0x7f1a7df19000)

4. lsmod | grep mlx
mlx5_ib   138046  0
mlx5_core 108376  1 mlx5_ib
mlx4_ib   199880  0
ib_sa  43732  5 rdma_cm,ib_cm,mlx4_ib,rdma_ucm,ib_ipoib
mlx4_en   137047  0
ib_mad 51544  4 ib_cm,ib_sa,mlx4_ib,ib_umad
vxlan  37619  1 mlx4_en
ib_core   130498  12 
rdma_cm,ib_cm,ib_sa,iw_cm,mlx4_ib,mlx5_ib,ib_mad,ib_ucm,ib_umad,ib_uverbs,rdma_ucm,ib_ipoib
mlx4_core 332375  2 mlx4_en,mlx4_ib
compat 13738  17 
rdma_cm,ib_cm,ib_sa,iw_cm,mlx4_en,mlx4_ib,mlx5_ib,ib_mad,ib_ucm,ib_addr,ib_core,ib_umad,ib_uverbs,mlx4_core,mlx5_core,rdma_ucm,ib_ipoib
ptp18933  3 igb,ixgbe,mlx4_en

Best regards,
Raghav

On Sat, Apr 4, 2015 at 5:04 PM Olga Shern mailto:olgas 
at mellanox.com>> wrote:
Hi Raghav,

After running /etc/init.d/openibd restart you don?t need to load the modules, 
they are loaded by the openibd script.
Can you try to run :
/etc/init.d/openibd stop
Verify that modules are not loaded
/etc/init.d/openib start

If it won?t help:
What Mellanox NIC do you have on the ?problematic? machine?
What command line do you use to run the application?

Please send output of:

1.   ?lspci | grep Mellanox?

2.   ibdev2netdev

3.   ldd 

4.   lsmod

Thanks
Olga


From: Raghav Sethi [mailto:raghavs at 
CS.Princeton.EDU<mailto:ragh...@cs.princeton.edu>]
Sent: Saturday, April 04, 2015 11:54 PM
To: Olga Shern; Adrien Mazarguil; dev at dpdk.org<mailto:dev at dpdk.org>; 
Xiaozhou Li

Subject: Re: [dpdk-dev] [PATCH] doc: update mlx4 usage and dependencies

Hi Olga,

Thanks for your reply. OFED version was 2.4-1.0.4 for ubuntu14.04-x86_64

I tried both variants:
- Compiling with dynamic linking against OFED libraries
- Compiling with static linking against dpdk.org<http://dpdk.org> libraries

Both have the same issue.

Best,
Raghav

On Sat, Apr 4, 2015 at 4:49 PM Olga Shern mailto:olgas 
at mellanox.com>> wrote:
Hi Raghav,

What OFED version did you install?

There are 2 ways to compile mlx4:
1. You can compile it dynamically with the libibverbs  that are coming with 
Mellanox_OFED 2.4
2. To get better performance: compile it statically with libibverbs and libmlx4 
that can be downloaded from http://dpdk.org/download, the README inside 
librte_pmd_mlx4 explains how to do it
 If you compile the pmd statically then MLNX_OFED is needed only for kernel 
modules.

Best Regards,
Olga


-Original Message-
From: dev [mailto:dev-bounces at dpdk.org<mailto:dev-boun...@dpdk.org>] On 
Behalf Of Raghav Sethi
Sent: Friday, April 03, 2015 9:21 PM
To: Adrien Mazarguil; dev at dpdk.org<mailto:dev at dpdk.org>; Xiaozhou Li
Subject: Re: [dpdk-dev] [PATCH] doc: update mlx4 usage and dependencies

Hi Adrien,

Quick update: So I just tried the setup again on a new machine with the exact 
same hardware - installed OFED and compiled DPDK 2.0.0. Works like a charm.

Still getting the issue on the old machine (also upgraded to 2.0.0 FWIW).
>From the error message it appears that the libraries are incorrectly 
>installed/configured. However, the OFED uninstall script removes the libraries 
>in question (libmlx5-rdmav2.so, libibverbs

[dpdk-dev] Mellanox Flow Steering

[Olga Shern]

Hi Raghav, 

You are right with your observations,  Mellanox PMD and mlx4_en (kernel driver) 
are co-exist.
When DPDK application run, all traffic is redirected to DPDK application. When 
DPDK application exit the traffic is received by mlx4_en driver.

Regarding ethtool configuration you did, it influence only mlx4_en driver, it 
doesn't influence Mellanox PMD queues.

Mellanox PMD doesn't support Flow Director, like you mention, and we are 
working to add it.
Currently the only way to spread traffic between different PMD queues is using 
RSS. 

Best Regards,
Olga

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Raghav Sethi
Sent: Sunday, April 12, 2015 7:18 PM
To: Zhou, Danny; dev at dpdk.org
Subject: Re: [dpdk-dev] Mellanox Flow Steering

Hi Danny,

Thanks, that's helpful. However, Mellanox cards don't support Intel Flow 
Director, so how would one go about installing these rules in the NIC? The only 
technique the Mellanox User Manual (
http://www.mellanox.com/related-docs/prod_software/Mellanox_EN_for_Linux_User_Manual_v2_0-3_0_0.pdf)
lists to use Flow Steering is the ethtool based method.

Additionally, the mlx4_core driver is used both by DPDK PMD and otherwise 
(unlike the igb_uio driver, which needs to be loaded to use PMD) and it seems 
weird that only the packets affected by the rules don't hit the DPDK 
application. That indicates to me that the NIC is dealing with the rules 
somehow even though a DPDK application is running.

Best,
Raghav

On Sun, Apr 12, 2015 at 7:47 AM Zhou, Danny  wrote:

> Currently, the DPDK PMD and NIC kernel driver cannot drive a same NIC 
> device simultaneously. When you use ethtool to setup flow director 
> filter, the rules are written to NIC via ethtool support in kernel 
> driver. But when DPDK PMD is loaded to drive same device, the rules 
> previously written by ethtool/kernel_driver will be invalid, so you 
> may have to use DPDK APIs to rewrite your rules to the NIC again.
>
> The bifurcated driver is designed to provide a solution to support the 
> kernel driver and DPDK coexist scenarios, but it has security concern 
> so netdev maintainer rejects it.
>
> It should not be a Mellanox hardware problem, if you try it on Intel 
> NIC the result is same.
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Raghav Sethi
> > Sent: Sunday, April 12, 2015 1:10 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] Mellanox Flow Steering
> >
> > Hi folks,
> >
> > I'm trying to use the flow steering features of the Mellanox card to 
> > effectively use a multicore server for a benchmark.
> >
> > The system has a single-port Mellanox ConnectX-3 EN, and I want to 
> > use 4
> of
> > the 32 cores present and 4 of the 16 RX queues supported by the 
> > hardware (i.e. one RX queue per core).
> >
> > I assign RX queues to each of the cores, but obviously without flow 
> > steering (all the packets have the same IP and UDP headers, but 
> > different dest MACs in the ethernet headers) each of the packets hits one 
> > core.
> I've
> > set up the client such that it sends packets with a different 
> > destination MAC for each RX queue (e.g. RX queue 1 should get 
> > 10:00:00:00:00:00, RX queue 2 should get 10:00:00:00:00:01 and so on).
> >
> > I try to accomplish this by using ethtool to set flow steering rules
> (e.g.
> > ethtool -U p7p1 flow-type ether dst 10:00:00:00:00:00 action 1 loc 
> > 1, ethtool -U p7p1 flow-type ether dst 10:00:00:00:00:01 action 2 loc 2..).
> >
> > As soon as I set up these rules though, packets matching them just 
> > stop hitting my application. All other packets go through, and 
> > removing the rules also causes the packets to go through. I'm pretty 
> > sure my
> application
> > is looking at all the queues, but I tried changing the rules to try 
> > a
> rule
> > for every single destination RX queue (0-16), and that doesn't work
> either.
> >
> > If it helps, my code is based on the l2fwd sample application, and 
> > is
> here:
> > https://gist.github.com/raghavsethi/416fb77d74ccf81bd93e
> >
> > Also, I added the following to my /etc/init.d: options mlx4_core 
> > log_num_mgm_entry_size=-1, and restarted the driver before any of 
> > these tests.
> >
> > Any ideas what might be causing my packets to drop? In case this is 
> > a Mellanox issue, should I be talking to their customer support?
> >
> > Best,
> > Raghav Sethi
>

[dpdk-dev] Mellanox Flow Steering

[Olga Shern]

Hi Danny, 

Please see below

Best Regards,
Olga

-Original Message-
From: Zhou, Danny [mailto:danny.z...@intel.com] 
Sent: Monday, April 13, 2015 2:30 AM
To: Olga Shern; Raghav Sethi; dev at dpdk.org
Subject: RE: [dpdk-dev] Mellanox Flow Steering

Thanks for clarification Olga. I assume when PMD is upgraded to support flow 
director, the rules should be only set by PMD while DPDK application is 
running, right?
[Olga ] Right
 Also, when DPDK application exits, the rules previously written by the PMD are 
invalid then user needs to reset rules by ethtool via mlx4_en driver.
[Olga ] Right

I think it does not make sense to allow two drivers, one in kernel and another 
in user space, to control a same NIC device simultaneously. Or a control plane 
synchronization mechanism is needed between two drivers.
[Olga ] Agree :) We are looking for a solution 

A master driver responsible for NIC control solely is expected.
[Olga ] Or there should be synchronization mechanism as you mentioned before 

> -Original Message-
> From: Olga Shern [mailto:olgas at mellanox.com]
> Sent: Monday, April 13, 2015 4:39 AM
> To: Raghav Sethi; Zhou, Danny; dev at dpdk.org
> Subject: RE: [dpdk-dev] Mellanox Flow Steering
> 
> Hi Raghav,
> 
> You are right with your observations,  Mellanox PMD and mlx4_en (kernel 
> driver) are co-exist.
> When DPDK application run, all traffic is redirected to DPDK 
> application. When DPDK application exit the traffic is received by mlx4_en 
> driver.
> 
> Regarding ethtool configuration you did, it influence only mlx4_en driver, it 
> doesn't influence Mellanox PMD queues.
> 
> Mellanox PMD doesn't support Flow Director, like you mention, and we are 
> working to add it.
> Currently the only way to spread traffic between different PMD queues is 
> using RSS.
> 
> Best Regards,
> Olga
> 
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Raghav Sethi
> Sent: Sunday, April 12, 2015 7:18 PM
> To: Zhou, Danny; dev at dpdk.org
> Subject: Re: [dpdk-dev] Mellanox Flow Steering
> 
> Hi Danny,
> 
> Thanks, that's helpful. However, Mellanox cards don't support Intel 
> Flow Director, so how would one go about installing these rules in the 
> NIC? The only technique the Mellanox User Manual (
> http://www.mellanox.com/related-docs/prod_software/Mellanox_EN_for_Lin
> ux_User_Manual_v2_0-3_0_0.pdf) lists to use Flow Steering is the 
> ethtool based method.
> 
> Additionally, the mlx4_core driver is used both by DPDK PMD and 
> otherwise (unlike the igb_uio driver, which needs to be loaded to use 
> PMD) and it seems weird that only the packets affected by the rules don't hit 
> the DPDK application. That indicates to me that the NIC is dealing with the 
> rules somehow even though a DPDK application is running.
> 
> Best,
> Raghav
> 
> On Sun, Apr 12, 2015 at 7:47 AM Zhou, Danny  wrote:
> 
> > Currently, the DPDK PMD and NIC kernel driver cannot drive a same 
> > NIC device simultaneously. When you use ethtool to setup flow 
> > director filter, the rules are written to NIC via ethtool support in 
> > kernel driver. But when DPDK PMD is loaded to drive same device, the 
> > rules previously written by ethtool/kernel_driver will be invalid, 
> > so you may have to use DPDK APIs to rewrite your rules to the NIC again.
> >
> > The bifurcated driver is designed to provide a solution to support 
> > the kernel driver and DPDK coexist scenarios, but it has security 
> > concern so netdev maintainer rejects it.
> >
> > It should not be a Mellanox hardware problem, if you try it on Intel 
> > NIC the result is same.
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Raghav Sethi
> > > Sent: Sunday, April 12, 2015 1:10 PM
> > > To: dev at dpdk.org
> > > Subject: [dpdk-dev] Mellanox Flow Steering
> > >
> > > Hi folks,
> > >
> > > I'm trying to use the flow steering features of the Mellanox card 
> > > to effectively use a multicore server for a benchmark.
> > >
> > > The system has a single-port Mellanox ConnectX-3 EN, and I want to 
> > > use 4
> > of
> > > the 32 cores present and 4 of the 16 RX queues supported by the 
> > > hardware (i.e. one RX queue per core).
> > >
> > > I assign RX queues to each of the cores, but obviously without 
> > > flow steering (all the packets have the same IP and UDP headers, 
> > > but different dest MACs in the ethernet headers) each of the packets hits 
> > > one core.
> > I've
> > > set up the client such that it sen

[dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3 problem!

[Olga Shern]

Hi Kang, 

You probably compiled  the downloaded libraries using dynamic linkage, prior to 
the static one you specified here.
You need to remove  them from /usr/local/libs and also please delete 
/usr/local/include/infiniband 

Let me know if it solves your problem.

Best Regards,
Olga


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of ZhanYing Kang
Sent: Tuesday, April 21, 2015 11:45 AM
To: dev
Subject: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3 problem!

When  I'm  run testpmd with DPDK 2.0 and the Mellanox ConnectX-3. I get a error.

 Here are my questions:
 1> lspci |grep Mell
02:00.0 Network controller: Mellanox Technologies MT27500 Family [ConnectX-3]

 2> compile libibverbs-1.1.7mlnx1 && libmlx4-1.0.5mlnx1 export 
EXTRA_CFLAGS=-I/DPDK/mlx4/install/usr/local/include
export EXTRA_LDFLAGS=-L/DPDK/mlx4/install/usr/local/lib

3> compile dpdk v2.0 with x86_64-native-linuxapp-gcc config and 
3> CONFIG_RTE_LIBRTE_MLX4_PMD=y

 4> modprobe -a ib_uverbs mlx4_en mlx4_core mlx4_ib  lsmod mlx4_ib 135033 0 - 
Live 0xa0215000 (O) ib_sa 24721 1 mlx4_ib, Live 0xa0209000 (O) 
ib_mad 31664 2 mlx4_ib,ib_sa, Live 0xa01fc000 (O) mlx4_en 92808 0 - 
Live 0xa01b1000 (O) mlx4_core 226516 2 mlx4_ib,mlx4_en, Live 
0xa0163000 (O) ib_uverbs 43309 0 - Live 0xa0133000 (O) ib_core 
79534 4 mlx4_ib,ib_sa,ib_mad,ib_uverbs, Live 0xa010 (O) ib_addr 
4273 2 ib_uverbs,ib_core, Live 0xa00fa000 (O) compat 4948 8 
mlx4_ib,ib_sa,ib_mad,mlx4_en,mlx4_core,ib_uverbs,ib_core,ib_addr, Live 
0xa00ad000 (O)  5> run testpmd
  # ./testpmd-mlx  -c 0xff00 -n 4 -w :02:00.0 -- --rxq=2 --txq=2 -i
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 6 on socket 0
EAL: Detected lcore 7 as core 7 on socket 0
EAL: Detected lcore 8 as core 0 on socket 0
EAL: Detected lcore 9 as core 1 on socket 0
EAL: Detected lcore 10 as core 2 on socket 0
EAL: Detected lcore 11 as core 3 on socket 0
EAL: Detected lcore 12 as core 4 on socket 0
EAL: Detected lcore 13 as core 5 on socket 0
EAL: Detected lcore 14 as core 6 on socket 0
EAL: Detected lcore 15 as core 7 on socket 0
EAL: Support maximum 32 logical core(s) by configuration.
EAL: Detected 16 lcore(s)
EAL: Setting up memory...
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f5a2b80 (size = 0x20)
EAL: Ask a virtual area of 0x3100 bytes
EAL: Virtual area found at 0x7f59fa60 (size = 0x3100)
EAL: Ask a virtual area of 0x7ec0 bytes
EAL: Virtual area found at 0x7f597b80 (size = 0x7ec0)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f597b40 (size = 0x20)
EAL: Ask a virtual area of 0x25000 bytes
EAL: Virtual area found at 0x7f572b20 (size = 0x25000)
EAL: Requesting 6144 pages of size 2MB from socket 0
EAL: TSC frequency is ~2394227 KHz
EAL: Master lcore 8 is ready (tid=2e1b7900;cpuset=[8])
EAL: lcore 11 is ready (tid=299b7700;cpuset=[11])
EAL: lcore 14 is ready (tid=281b4700;cpuset=[14])
EAL: lcore 15 is ready (tid=279b3700;cpuset=[15])
EAL: lcore 12 is ready (tid=291b6700;cpuset=[12])
EAL: lcore 9 is ready (tid=2caaf700;cpuset=[9])
EAL: lcore 10 is ready (tid=2c2ae700;cpuset=[10])
EAL: lcore 13 is ready (tid=289b5700;cpuset=[13])
EAL: PCI device :02:00.0 on NUMA socket -1
EAL:   probe driver: 15b3:1003 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_0" (VF: false)
PMD: librte_pmd_mlx4: 2 port(s) detected
PMD: librte_pmd_mlx4: bad state for port 1: "down" (1)
PMD: librte_pmd_mlx4: port 1 MAC address is 02:02:c9:fa:a4:81
PMD: librte_pmd_mlx4: bad state for port 2: "down" (1)
PMD: librte_pmd_mlx4: port 2 MAC address is 00:02:c9:fa:a4:82 Interactive-mode 
selected Configuring Port 0 (socket 0)
PMD: librte_pmd_mlx4: 0x7dffe0: TX queues number update: 0 -> 2
PMD: librte_pmd_mlx4: 0x7dffe0: RX queues number update: 0 -> 2
PMD: librte_pmd_mlx4: 0x7fffc81e67e0: flow configuration failed, errno=38: 
Function not implemented
PMD: librte_pmd_mlx4: 0x7fffc81e67e0: flow configuration failed, errno=38: 
Function not implemented
PMD: librte_pmd_mlx4: 0x7dffe0: QP flow attachment failed: Function not 
implemented Fail to configure port 0
EAL: Error - exiting with code: 1
  Cause: Start ports failed

 Best,
Kang!

[dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3 problem!

[Olga Shern]

Hi Kang,

Sorry for the late response.
ConnectX-3 VPI card that you have is supported. So there shouldn?t be any 
problem.
Please make sure to follow the instructions in 
http://www.dpdk.org/doc/guides/nics/mlx4.html
What MLNX_OFED did you install?
What is the output of ibdev2netdev?
Make sure, mlx4_core parameter log_num_mgm_entry_size = -1

Best Regards,
Olga


From: Arthas [mailto:kangzy1...@qq.com]
Sent: Wednesday, April 22, 2015 6:56 AM
To: Olga Shern; dev
Subject: Re: RE: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3 problem!

 3KS, Olga,
I try you suggestion and it can't start yet. My Mellanox ConnectX-3 card is 
"ConnectX?-3 VPI adapter card, dual-port QSFP, FDR IB   (56Gb/s) and 40/56GbE, 
PCIe3.0 x8 8GT/s, tall bracket,RoHS R6". May be the problem?

 # mstflint  -d 02:00.0 q
Image type:  FS2
FW Version:  2.33.5100
FW Release Date: 25.1.2015
Product Version: 02.33.51.00
Rom Info:type=PXE version=3.4.460 devid=4099
Device ID:   4099
Description: Node Port1Port2Sys image
GUIDs:   0002c90300faa480 0002c90300faa481 0002c90300faa482 
0002c90300faa483
MACs: 0002c9faa481 0002c9faa482
VSD:
PSID:MT_1090110019

Best Regards,
Kang
-- Original --
From:  "Olga Shern";mailto:ol...@mellanox.com>>;
Date:  Tue, Apr 21, 2015 09:34 PM
To:  "Arthas"mailto:kangzy1982 at qq.com>>; "dev"mailto:dev at dpdk.org>>;
Subject:  RE: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3 problem!

Hi Kang,

You probably compiled  the downloaded libraries using dynamic linkage, prior to 
the static one you specified here.
You need to remove  them from /usr/local/libs and also please delete 
/usr/local/include/infiniband

Let me know if it solves your problem.

Best Regards,
Olga


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of ZhanYing Kang
Sent: Tuesday, April 21, 2015 11:45 AM
To: dev
Subject: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3 problem!

When  I'm  run testpmd with DPDK 2.0 and the Mellanox ConnectX-3. I get a error.

 Here are my questions:
 1> lspci |grep Mell
02:00.0 Network controller: Mellanox Technologies MT27500 Family [ConnectX-3]

 2> compile libibverbs-1.1.7mlnx1 && libmlx4-1.0.5mlnx1 export 
EXTRA_CFLAGS=-I/DPDK/mlx4/install/usr/local/include
export EXTRA_LDFLAGS=-L/DPDK/mlx4/install/usr/local/lib

3> compile dpdk v2.0 with x86_64-native-linuxapp-gcc config and
3> CONFIG_RTE_LIBRTE_MLX4_PMD=y

 4> modprobe -a ib_uverbs mlx4_en mlx4_core mlx4_ib  lsmod mlx4_ib 135033 0 - 
Live 0xa0215000 (O) ib_sa 24721 1 mlx4_ib, Live 0xa0209000 (O) 
ib_mad 31664 2 mlx4_ib,ib_sa, Live 0xa01fc000 (O) mlx4_en 92808 0 - 
Live 0xa01b1000 (O) mlx4_core 226516 2 mlx4_ib,mlx4_en, Live 
0xa0163000 (O) ib_uverbs 43309 0 - Live 0xa0133000 (O) ib_core 
79534 4 mlx4_ib,ib_sa,ib_mad,ib_uverbs, Live 0xa010 (O) ib_addr 
4273 2 ib_uverbs,ib_core, Live 0xa00fa000 (O) compat 4948 8 
mlx4_ib,ib_sa,ib_mad,mlx4_en,mlx4_core,ib_uverbs,ib_core,ib_addr, Live 
0xa00ad000 (O)  5> run testpmd
  # ./testpmd-mlx  -c 0xff00 -n 4 -w :02:00.0 -- --rxq=2 --txq=2 -i
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 6 on socket 0
EAL: Detected lcore 7 as core 7 on socket 0
EAL: Detected lcore 8 as core 0 on socket 0
EAL: Detected lcore 9 as core 1 on socket 0
EAL: Detected lcore 10 as core 2 on socket 0
EAL: Detected lcore 11 as core 3 on socket 0
EAL: Detected lcore 12 as core 4 on socket 0
EAL: Detected lcore 13 as core 5 on socket 0
EAL: Detected lcore 14 as core 6 on socket 0
EAL: Detected lcore 15 as core 7 on socket 0
EAL: Support maximum 32 logical core(s) by configuration.
EAL: Detected 16 lcore(s)
EAL: Setting up memory...
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f5a2b80 (size = 0x20)
EAL: Ask a virtual area of 0x3100 bytes
EAL: Virtual area found at 0x7f59fa60 (size = 0x3100)
EAL: Ask a virtual area of 0x7ec0 bytes
EAL: Virtual area found at 0x7f597b80 (size = 0x7ec0)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f597b40 (size = 0x20)
EAL: Ask a virtual area of 0x25000 bytes
EAL: Virtual area found at 0x7f572b20 (size = 0x25000)
EAL: Requesting 6144 pages of size 2MB from socket 0
EAL: TSC frequency is ~2394227 KHz
EAL: Master lcore 8 is ready (tid=2e1b7900;cpuset=[8])
EAL: lcore 11 is ready (tid=299b7700;cpuset=[11])
EAL: lcore 14 is ready (tid=281b4700;cpuset=[14])
EAL: lcore 15 is ready (tid=279b3700;cpuset=[15])
EAL: lcore 12 

[dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

[Olga Shern]

Hi Kang,

I am glad you were able to fix the problem.
But I think there is some confusion here, it means that we need have better 
documentation ?
First step to work with Mellanox NIC is to install proper MLNX_OFED and FW from 
Mellanox.com
Seems that you did it.
Then you need to run /etc/init.d/openibd restart to load the needed modules.

For DPDK,  you need to configure your card to work as Ethernet, Mellanox VPI 
cards can be either Infiniband or Ethernet.
Use  connectx_port_config to configure it, as you did
After that you can run ibdev2netdev and ifconfig and verify that you have 
interfaces for Mellanox NIC ports.

Then you can compile DPDK with Mellanox PMD enabled. Mellanox PMD can be 
dynamically linked with the MLNX_OFED installed libibverbs and libmlx4 ? but 
the performance you get is not the best one.
Mellanox PMD can also be statically compiled with optimized libibverbs and 
libmlx4 that can be downloaded from dpdk.org site.

Let me know if it clear.
Best Regards,
Olga

From: Arthas [mailto:kangzy1...@qq.com]
Sent: Monday, April 27, 2015 6:07 AM
To: Arthas; Olga Shern; dev
Subject: Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

Hi, Olga,
I think I have solved this problem.
libibverbs & libmlx4 can't use dpdp.org and can't compile with static linking.
I try use libibverbs-1.1.8mlnx1-OFED.2.4.45.ga305acd.src.rpm & 
libmlx4-1.0.6mlnx1-OFED.2.4.0.1.2.src and compile with dynamic. This two 
package in MLNX_OFED version 2.4-1.0.0 source package.
and I use ofed_script  connectx_port_config  config Card with Ethernet mode .
The testpmd was started with no error! :)

Thanks a million!! :)

Best Regards!
Kang

-- Original --
From:  "Arthas";mailto:kangzy1...@qq.com>>;
Date:  Mon, Apr 27, 2015 10:37 AM
To:  "Olga Shern"mailto:olgas at mellanox.com>>; 
"dev"mailto:dev at dpdk.org>>;
Subject:  Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

3KS, Olga,
  My MLNX_OFED version 2.4-1.0.0 and libibverbs & libmlx4 download from 
dpdk.org.
 when i try to run ibdev2netdev , it don't output any message! :(
 Here is my environment.
 # uname -r
3.10.0-mlx
 # lsmod
mlx4_en 92824 0 - Live 0xa010f000 (O)
mlx4_ib 135033 0 - Live 0xa00e3000 (O)
ib_sa 24721 1 mlx4_ib, Live 0xa00d7000 (O)
ib_mad 31664 2 mlx4_ib,ib_sa, Live 0xa00ca000 (O)
mlx4_core 226516 2 mlx4_en,mlx4_ib, Live 0xa007c000 (O)
ib_uverbs 43309 0 - Live 0xa003f000 (O)
ib_core 79534 4 mlx4_ib,ib_sa,ib_mad,ib_uverbs, Live 0xa001d000 (O)
ib_addr 4273 2 ib_uverbs,ib_core, Live 0xa0017000 (O)
compat 4948 8 mlx4_en,mlx4_ib,ib_sa,ib_mad,mlx4_core,ib_uverbs,ib_core,ib_addr, 
Live 0xa0011000 (O)
 # mstflint  -d 02:00.0 q
Image type:  FS2
FW Version:  2.33.5100
FW Release Date: 25.1.2015
Product Version: 02.33.51.00
Rom Info:type=PXE version=3.4.460 devid=4099
Device ID:   4099
Description: Node Port1Port2Sys image
GUIDs:   0002c90300faa480 0002c90300faa481 0002c90300faa482 
0002c90300faa483
MACs: 0002c9faa481 0002c9faa482
VSD:
PSID:MT_1090110019
# ibv_devices
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
device node GUID
--  
 # ibv_devinfo  -l
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
0 HCAs found:

/sys/class/infiniband_verbs # ls
abi_version  uverbs0
 # find . -name "mlx4*"
./proc/irq/148/mlx4-32 at :02:00.0<mailto:./proc/irq/148/mlx4-32 at 
:02:00.0>
./proc/irq/147/mlx4-31 at :02:00.0<mailto:./proc/irq/147/mlx4-31 at 
:02:00.0>
./proc/irq/146/mlx4-30 at :02:00.0<mailto:./proc/irq/146/mlx4-30 at 
:02:00.0>
./proc/irq/145/mlx4-29 at :02:00.0<mailto:./proc/irq/145/mlx4-29 at 
:02:00.0>
./proc/irq/144/mlx4-28 at :02:00.0<mailto:./proc/irq/144/mlx4-28 at 
:02:00.0>
./proc/irq/143/mlx4-27 at :02:00.0<mailto:./proc/irq/143/mlx4-27 at 
:02:00.0>
./proc/irq/142/mlx4-26 at :02:00.0<mailto:./proc/irq/142/mlx4-26 at 
:02:00.0>
./proc/irq/141/mlx4-25 at :02:00.0<mailto:./proc/irq/141/mlx4-25 at 
:02:00.0>
./proc/irq/140/mlx4-24 at :02:00.0<mailto:./proc/irq/140/mlx4-24 at 
:02:00.0>
./proc/irq/139/mlx4-23 at :02:00.0<mailto:./proc/irq/139/mlx4-23 at 
:02:00.0>
./proc/irq/138/mlx4-22 at :02:00.0<mailto:./proc/irq/138/mlx4-22 at

[dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

[Olga Shern]

OK, great it is clear :)

From: Arthas [mailto:kangzy1...@qq.com]
Sent: Monday, April 27, 2015 12:17 PM
To: Olga Shern; dev
Subject: Re: RE: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

Hi, Olga
Yes, you are right!
"Mellanox PMD can also be statically compiled with optimized libibverbs and 
libmlx4 that can be downloaded from dpdk.org site."
Only libibverbs tools need compile with shared!  :)
and because my environment is busybox with my custom kernel, so the kernel 
version is very important yet.
the MLNX_OFED package contain a ofed-docs indicate it! :)

Best Regards!
Kang

-- Original --
From:  "Olga Shern";mailto:ol...@mellanox.com>>;
Date:  Mon, Apr 27, 2015 04:50 PM
To:  "Arthas"mailto:kangzy1982 at qq.com>>; "dev"mailto:dev at dpdk.org>>;
Subject:  RE: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

Hi Kang,

I am glad you were able to fix the problem.
But I think there is some confusion here, it means that we need have better 
documentation :)
First step to work with Mellanox NIC is to install proper MLNX_OFED and FW from 
Mellanox.com
Seems that you did it.
Then you need to run /etc/init.d/openibd restart to load the needed modules.

For DPDK,  you need to configure your card to work as Ethernet, Mellanox VPI 
cards can be either Infiniband or Ethernet.
Use  connectx_port_config to configure it, as you did
After that you can run ibdev2netdev and ifconfig and verify that you have 
interfaces for Mellanox NIC ports.

Then you can compile DPDK with Mellanox PMD enabled. Mellanox PMD can be 
dynamically linked with the MLNX_OFED installed libibverbs and libmlx4 - but 
the performance you get is not the best one.
Mellanox PMD can also be statically compiled with optimized libibverbs and 
libmlx4 that can be downloaded from dpdk.org site.

Let me know if it clear.
Best Regards,
Olga

From: Arthas [mailto:kangzy1...@qq.com]
Sent: Monday, April 27, 2015 6:07 AM
To: Arthas; Olga Shern; dev
Subject: Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

Hi, Olga,
I think I have solved this problem.
libibverbs & libmlx4 can't use dpdp.org and can't compile with static linking.
I try use libibverbs-1.1.8mlnx1-OFED.2.4.45.ga305acd.src.rpm & 
libmlx4-1.0.6mlnx1-OFED.2.4.0.1.2.src and compile with dynamic. This two 
package in MLNX_OFED version 2.4-1.0.0 source package.
and I use ofed_script  connectx_port_config  config Card with Ethernet mode .
The testpmd was started with no error! :)

Thanks a million!! :)

Best Regards!
Kang

-- Original --
From:  "Arthas";mailto:kangzy1...@qq.com>>;
Date:  Mon, Apr 27, 2015 10:37 AM
To:  "Olga Shern"mailto:olgas at mellanox.com>>; 
"dev"mailto:dev at dpdk.org>>;
Subject:  Re: [dpdk-dev] DPDK v2.0 testpmd with Mellanox ConnectX-3problem!

3KS, Olga,
  My MLNX_OFED version 2.4-1.0.0 and libibverbs & libmlx4 download from 
dpdk.org.
when i try to run ibdev2netdev , it don't output any message! :(
Here is my environment.
# uname -r
3.10.0-mlx
# lsmod
mlx4_en 92824 0 - Live 0xa010f000 (O)
mlx4_ib 135033 0 - Live 0xa00e3000 (O)
ib_sa 24721 1 mlx4_ib, Live 0xa00d7000 (O)
ib_mad 31664 2 mlx4_ib,ib_sa, Live 0xa00ca000 (O)
mlx4_core 226516 2 mlx4_en,mlx4_ib, Live 0xa007c000 (O)
ib_uverbs 43309 0 - Live 0xa003f000 (O)
ib_core 79534 4 mlx4_ib,ib_sa,ib_mad,ib_uverbs, Live 0xa001d000 (O)
ib_addr 4273 2 ib_uverbs,ib_core, Live 0xa0017000 (O)
compat 4948 8 mlx4_en,mlx4_ib,ib_sa,ib_mad,mlx4_core,ib_uverbs,ib_core,ib_addr, 
Live 0xa0011000 (O)
# mstflint  -d 02:00.0 q
Image type:  FS2
FW Version:  2.33.5100
FW Release Date: 25.1.2015
Product Version: 02.33.51.00
Rom Info:type=PXE version=3.4.460 devid=4099
Device ID:   4099
Description: Node Port1Port2Sys image
GUIDs:   0002c90300faa480 0002c90300faa481 0002c90300faa482 
0002c90300faa483
MACs: 0002c9faa481 0002c9faa482
VSD:
PSID:MT_1090110019
# ibv_devices
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
device node GUID
--  
# ibv_devinfo  -l
libibverbs: Warning: dlopen(NULL) failed, assuming static linking.
libibverbs: Warning: no userspace device-specific driver found for 
/sys/class/infiniband_verbs/uverbs0
When linking libibverbs statically, driver must be statically linked 
too.
0 HCAs found:

/sys/class/infiniband_verbs # ls
abi_version  uverbs0
# find . -name "mlx4*"
./proc/irq/148/mlx4-32 at :02:00.0<mailto:./proc/irq/148/mlx4-

Re: [dpdk-dev] [PATCH v2] doc: add tso capabilities feature for mlx5

[Olga Shern]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Monday, January 23, 2017 2:30 PM
> To: Elad Persiko ; dev@dpdk.org; Adrien Mazarguil
> 
> Subject: Re: [dpdk-dev] [PATCH v2] doc: add tso capabilities feature for mlx5
> 
> On 1/10/2017 9:18 AM, Elad Persiko wrote:
> >
> > Thanks,
> > The feature is not supported on MLX4. I will fix it on V2
> 
> The new version of this patch will be squashed to "net/mlx5: last WQE no
> room inline" patchset, right?

Yes, you are right 

Best Regards,
Olga

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] ConnectX4 100GbE - Compilation problem

[Olga Shern]

Hi George,

You are right, this is the expected behavior.
Every new DPDK version that is released supported on top of latest available 
MLNX_OFED and this is documented  in the RN.
For DPDK 16.07 you will need to use MLNX_OFED 3.3

Best Regards,
Olga

From: george@gmail.com [mailto:george@gmail.com]
Sent: Sunday, December 18, 2016 6:06 PM
To: Olga Shern 
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] ConnectX4 100GbE - Compilation problem

Hi again,

I have a follow up question. I noticed that when I compile DPDK with 
CONFIG_RTE_LIBRTE_MLX5_PMD=y, the compilation fate depends upon the OFED 
version that I have.
To become more clear, with DPDK 16.11 and OFED 3.4-2.0.0.0 it compiles, but 
DPDK 16.07 and the same OFED fails with:

== Build drivers/net/mlx5
  CC mlx5.o
  PMDINFO mlx5.o.pmd.c
  CC mlx5.o.pmd.o
  LD mlx5.o
  CC mlx5_rxq.o
  CC mlx5_txq.o
  CC mlx5_rxtx.o
In file included from /opt/dpdk/drivers/net/mlx5/mlx5.h:41:0,
 from /opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c:65:
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c: In function ‘mlx5_mpw_new’:
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c:911:9: error: ‘MLX5_OPCODE_LSO_MPW’ 
undeclared (first use in this function)
 MLX5_OPCODE_LSO_MPW);
 ^
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c:911:9: note: each undeclared identifier 
is reported only once for each function it appears in
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c: In function ‘mlx5_mpw_inline_new’:
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c:1110:13: error: ‘MLX5_OPCODE_LSO_MPW’ 
undeclared (first use in this function)
 MLX5_OPCODE_LSO_MPW);
 ^
/opt/dpdk/mk/internal/rte.compile-pre.mk:138<http://rte.compile-pre.mk:138>: 
recipe for target 'mlx5_rxtx.o' failed
make[6]: *** [mlx5_rxtx.o] Error 1
/opt/dpdk/mk/rte.subdir.mk:61<http://rte.subdir.mk:61>: recipe for target 
'mlx5' failed
make[5]: *** [mlx5] Error 2
/opt/dpdk/mk/rte.subdir.mk:61<http://rte.subdir.mk:61>: recipe for target 'net' 
failed
make[4]: *** [net] Error 2
/opt/dpdk/mk/rte.sdkbuild.mk:78<http://rte.sdkbuild.mk:78>: recipe for target 
'drivers' failed
make[3]: *** [drivers] Error 2
/opt/dpdk/mk/rte.sdkroot.mk:123<http://rte.sdkroot.mk:123>: recipe for target 
'all' failed
make[2]: *** [all] Error 2
/opt/dpdk/mk/rte.sdkinstall.mk:84<http://rte.sdkinstall.mk:84>: recipe for 
target 'pre_install' failed
make[1]: *** [pre_install] Error 2
/opt/dpdk/mk/rte.sdkroot.mk:98<http://rte.sdkroot.mk:98>: recipe for target 
'install' failed
make: *** [install] Error 2

Is there a way to have DPDK compiled with MLX5 support across a variety of DPDK 
versions (i.e, from 2.2.0 up to 16.11)?

Thanks in advance and best regards,
Georgios




On Sun, Dec 18, 2016 at 8:58 AM, 
mailto:george@gmail.com>> wrote:
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 
mailto:ol...@mellanox.com>> 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<mailto:dev-boun...@dpdk.org>] On Behalf 
Of george@gmail.com<mailto:george@gmail.com>
Sent: Friday, December 16, 2016 4:46 PM
To: Georgios Katsikas mailto:george@gmail.com>>; 
dev@dpdk.org<mailto: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<http://rte.compile-pre.mk:138>: 
recipe for target 'mlx5.o'
failed
make[6]: *** [mlx5.o] Error 1
/opt/dpdk/mk/rte.subdir.mk:61<http://rte.subdir.mk:61>: recipe for target 
'mlx5' failed
make[5]: *** [mlx5] Error 2
/opt/dpdk/mk/rte.subdir.mk:61<http://rte.subdir.mk:61>: recipe for target 'net' 
failed
make[4]: *** [net] Error 2
/opt/dpdk/mk/rte.sdkbuild.mk:78<http://rte.sdkbuild.mk:78>: recipe for target 
'drivers' failed
make[3]: *** [drivers] Error 2
/opt/dpdk/mk/rte.sdkroot.mk:126<http://rte.sdkroot.mk:126>: recipe for target 
'all' failed
make[2]: *** [all] Error 2
/opt/dpdk/mk/rte.sdkinstall.mk:85<http://rte.sdkinstall.mk:85>: recipe for 
ta

Re: [dpdk-dev] [PATCH 0/4] catch up TILE-Gx support in DPDK

[Olga Shern]

Hi Thomas,  All

Mellanox agrees to remove TILE-Gx support from DPDK.org, but will continue to 
support customers using DPDK. 
Customer that needs support should contact Mellanox directly.

Best Regards,
Olga


> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Saturday, February 18, 2017 11:30 AM
> To: Chris Metcalf 
> Cc: Vincent JARDIN ; Bruce Richardson
> ; Jerin Jacob
> ; Olivier Matz
> ; Liming Sun ; Olga Shern
> ; Yael Shenhav ;
> dev@dpdk.org
> Subject: Re: [PATCH 0/4] catch up TILE-Gx support in DPDK
> 
> 2017-02-17 20:52, Chris Metcalf:
> > This patch series allows DPDK to build for TILE-Gx as of version 17.02.
> >
> > A required library (libgxio) had not been made publicly available.
> > It is now available as source here:
> >
> >
> > http://www.mellanox.com/repository/solutions/tile-scm/libgxio-1.0.tar.
> > xz
> >
> > it has also been folded into the binary release of the generic
> > toolchain that we periodically update on that website; for more
> > information about the toolchain tarballs, see here:
> >
> >   http://www.mellanox.com/repository/solutions/tile-scm/
> >
> > Note that the toolchain components were updated slightly in this
> > release of the tarballs relative to what was there before.
> 
> Thank you.
> Some of these changes (being able to compile on a free toolchain) should
> have been done since the beginning. Better later than never :) I think we
> won't allow any new component in DPDK which cannot be built freely, in the
> future (lessons learned).
> 
> > Hopefully, with DPDK now working on TILE-Gx again, there may be
> > interest from someone in the community in taking on a maintenance
> > role.  At this point, the Mellanox engineering team responsible for
> > TILE-Gx is largely focused on working on future chips based on ARMv8,
> > so unfortunately we won't have much bandwidth for TILE-Gx support going
> forward.
> 
> So do you mean that the TILE-Gx maintainers officially give up on their role?
> Then please update the MAINTAINERS file.
> 
> > If it still seems like removal makes sense now or at some point in the
> > future, it would probably at least be good to apply these patches so
> > there is a baseline to pick it up from later.
> 
> I agree. We can apply these patches before removing the whole
> architecture.
> 
> > Liming Sun, the tile dpdk maintainer, has reviewed these changes (he
> > sits next to me); if it's more appropriate, he can resend these
> > changes with his Signed-off-by as well.  I took on this work since I
> > was more familiar with libgxio and the details of our toolchain (I am
> > the maintainer for the tile architecture for Linux and glibc).
> 
> I think it is OK as is.

Re: [dpdk-dev] [PATCH v4 08/12] net/failsafe: support offload capabilities

[Olga Shern]

L;w

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gaëtan Rivet
> Sent: Thursday, June 01, 2017 5:38 PM
> To: Stephen Hemminger 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 08/12] net/failsafe: support offload
> capabilities
> 
> On Wed, May 31, 2017 at 08:23:09AM -0700, Stephen Hemminger wrote:
> > On Mon, 29 May 2017 15:42:20 +0200
> > Gaetan Rivet  wrote:
> >
> > > Signed-off-by: Gaetan Rivet 
> > > Acked-by: Olga Shern 
> > > ---
> > >  doc/guides/nics/features/failsafe.ini |   6 ++
> > >  drivers/net/failsafe/failsafe_ops.c   | 131
> +-
> > >  2 files changed, 135 insertions(+), 2 deletions(-)
> >
> > Once again what about case of dumb synthetic NIC combined with SR-IOV
> VF?
> > The VF has offloads the virtual NIC does not.
> >
> 
> The rules for capabilities are a little complicated.
> In the case both VF and the virtual NIC are present at launch, then the 
> logical
> AND is done both their capabilities sets.
> If one has additional capabilities that the user is requesting, and the 
> fail-safe
> recognize them (currently, all RX offloads, as TX offloads were not yet
> expressed by flags), and this capability is not supported by one slave, then
> this offload is disabled in the configuration.
> 
> > What about late plugin. how do you program the offloads of the later
> > arriving VF device.
> 
> If the VF is not present at launch, then the fail-safe reads only the set of
> capabilities from the fallback device. It does not have to do any AND-ing of
> the flags.
> 
> The consequence is that upon plugin of the VF, the latter has to respect the
> current running configuration. Probing will actually fail if some capability 
> is not
> supported (depending on PMDs), and the running configuration is not
> updated as it is considered "live".
> 
> There are only two solutions to this, either:
> 
> * Complicate a lot the fail-safe design and the rules applied in
>   the decision made on NIC configuration. The user then has bad
>   surprises upon seeing that his performance have been degraded
>   for arcane reasons.
> 
> * Emulate in software the offloads and try to advertize as many as
>   possible. This is done for example in the TAP PMD for some flags,
>   allowing those offloads to be used with hardware NICs.
>   The user then has a clear view of the available offloads by comparing
>   both sets of capabilities.
> 
> --
> Gaëtan Rivet
> 6WIND

Re: [dpdk-dev] Mellanox external dependencies...

[Olga Shern]

Hi Ananda, 

> 
> The following link has support for DPDK 16.11 and DPDK 2.2.
> 
> http://www.mellanox.com/page/products_dyn?product_family=209&mtag=
> pmd_for_dpdk
>
[Olga] This link is for MLNX_DPDK releases  that Mellanox maintains on top of 
dpdk.org versions
We support any version that is released on dpdk.org 
 
> 
> 
> I did not find the mellonox drivers compatible for DPDK 16.04. Could you
> please point me to the right version of libibverbs, libmlx4 and Kernel modules
> (mlx4_core, mlx4_en, mlx4_ib and ib_uverbs) that can be used with DPDK
> 16.04.
> 
[Olga] The instructions for latest DPDK version that was released (17.02)  you 
can find here:
http://dpdk.org/doc/guides/nics/mlx4.html 

for 16.04: 
http://dpdk.org/doc/guides-16.04/nics/mlx4.html 

We didn’t test 16.04 with latest MLNX_OFED that was released, but for mlx4 
there should not be any problem with it.
http://www.mellanox.com/page/software_overview_ib 

Let me know if you have any issue.

By the way, what is the reason using 16.04? 
16.11 is LTS version in the community, any chance you can use it?

Best Regards,
Olga  

____
Olga Shern 
SW Director DPDK 
Mellanox Technologies, Raanana Israel

Re: [dpdk-dev] [PATCH dpdk 0/5] ppc64/spapr: Attempt to use on POWER8

[Olga Shern]

Alexey, 

Mellanox support DPDK only on Ethernet, no IB.
And yes, you need to install Mellanox drivers , OFED, to support it.

What NIC do you have? 

Best Regards,
Olga


Olga Shern 
SW Director DPDK 
Mellanox Technologies, Raanana Israel




> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Alexey
> Kardashevskiy
> Sent: Thursday, April 20, 2017 10:24 AM
> To: dev@dpdk.org
> Cc: Alexey Kardashevskiy ; j...@zurich.ibm.com;
> Gowrishankar Muthukrishnan 
> Subject: [dpdk-dev] [PATCH dpdk 0/5] ppc64/spapr: Attempt to use on
> POWER8
> 
> Hi!
> 
> This is my first attempt to use DPDK on POWER8 machine and yet
> unsuccessful as it turned out DPDK only supports IB-Mellanox (I only got
> ethernet-Mellanox, and requires OFED), rmmod on Intel 40Gb module
> produces PCI errors (unrelated to DPDK) and Broadcom bnx2x has few issues
> (below) and still crashes as I suspect I got DMA mapping wrong, here is a
> backtrace:
> 
> Configuring Port 0 (socket 0)
> PMD: bnx2x_issue_dmae_with_comp(): DMAE timeout!
> PANIC in bnx2x_write_dmae():
> DMAE failed (-1)22: [/lib/powerpc64le-linux-
> gnu/libc.so.6(__libc_start_main+0xb8) [0x3fffb7c23298]]
> 21: [/lib/powerpc64le-linux-gnu/libc.so.6(+0x2309c) [0x3fffb7c2309c]]
> 20: [/home/aik/pbuild/dpdk_build/app/testpmd(main+0x228) [0x100255d0]]
> 19: [/home/aik/pbuild/dpdk_build/app/testpmd(start_port+0x5dc)
> [0x1002341c]]
> 18: [/home/aik/pbuild/dpdk_build/app/testpmd(rte_eth_dev_start+0xc4)
> [0x1008b3c0]]
> 17: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x10117550]]
> 16: [/home/aik/pbuild/dpdk_build/app/testpmd(bnx2x_init+0x204)
> [0x100f7210]]
> 15: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100f6888]]
> 14: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100ee7f4]]
> 13:
> [/home/aik/pbuild/dpdk_build/app/testpmd(ecore_func_state_change+0x
> 250) [0x10127794]]
> 12: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x1012734c]]
> 11: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x10126830]]
> 10: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x10126618]]
> 9: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x10100a98]]
> 8: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100ffe00]]
> 7: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100de614]]
> 6: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100de4cc]]
> 5: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x101063c0]]
> 4: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100e1f6c]]
> 3: [/home/aik/pbuild/dpdk_build/app/testpmd(bnx2x_write_dmae+0x11c)
> [0x100e1e40]]
> 2: [/home/aik/pbuild/dpdk_build/app/testpmd(__rte_panic+0x8c)
> [0x100b3e58]]
> 1: [/home/aik/pbuild/dpdk_build/app/testpmd(rte_dump_stack+0x40)
> [0x100b3cc4]]
> 
> Thread 1 "testpmd" received signal SIGABRT, Aborted.
> 0x3fffb7c3edb0 in __GI_raise (sig=) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> 
> Still, some fixes are quite obvious and straigtforward.
> 
> This is based on sha1
> 2fc8e0bf0 Olivier Matz "log: fix dump of registered logs when disabled".
> 
> Please comment. Thanks.
> 
> 
> 
> Alexey Kardashevskiy (5):
>   vfio/ppc64/spapr: Use correct structures for add/remove windows
>   pci: Initialize common rte driver pointer
>   RFC: bnx2x: Update firmware versions
>   vfio: Do try setting IOMMU type if already set
>   RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map
> 
>  lib/librte_eal/linuxapp/eal/eal_vfio.h |  8 +
>  drivers/net/bnx2x/bnx2x.c  |  4 +--
>  lib/librte_eal/common/eal_common_pci.c |  1 +
> lib/librte_eal/linuxapp/eal/eal_vfio.c | 62 +++
> ---
>  4 files changed, 46 insertions(+), 29 deletions(-)
> 
> --
> 2.11.0

[dpdk-dev] Compilation error on Power8 with RC3

[Olga Shern]

Hi,

We see the following compilation error on Power8,  Ubuntu15.04 with DPDK2.2 RC3:


In file included from /download/dpdk/app/test/test_hash_scaling.c:35:0:
/download/dpdk/ppc_64-power8-linuxapp-gcc/include/rte_hash.h:70:70: error: 
unknown type name 'size_t'
typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2, size_t 
key_len);
  ^
/download/dpdk/ppc_64-power8-linuxapp-gcc/include/rte_hash.h:120:48: error: 
unknown type name 'rte_hash_cmp_eq_t'
void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func);
^
/download/dpdk/mk/internal/rte.compile-pre.mk:126: recipe for target 
'test_hash_scaling.o' failed
make[5]: *** [test_hash_scaling.o] Error 1
/download/dpdk/mk/rte.subdir.mk:61: recipe for target 'test' failed
make[4]: *** [test] Error 2
/download/dpdk/mk/rte.sdkbuild.mk:77: recipe for target 'app' failed
make[3]: *** [app] Error 2
/download/dpdk/mk/rte.sdkroot.mk:123: recipe for target 'all' failed
make[2]: *** [all] Error 2
/download/dpdk/mk/rte.sdkinstall.mk:84: recipe for target 'pre_install' failed
make[1]: *** [pre_install] Error 2
/download/dpdk/mk/rte.sdkroot.mk:98: recipe for target 'install' failed
make: *** [install] Error 2

Best Regards,
Olga

[dpdk-dev] [PATCH] mlx4: update documentation

[Olga Shern]

-Split "Features" and "Limitations" sections.
-Update limitations with missing information.
-Update prerequisites with supported MLNX_OFED release, firmware and
 CPU architectures.
-Enhance usage example with openibd script.

Signed-off-by: Olga Shern 
Signed-off-by: Adrien Mazarguil 
---
 doc/guides/nics/mlx4.rst |   24 +++-
 1 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index 562db06..62f0c31 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -78,8 +78,8 @@ long as they share the same MAC address.

 Compiling librte_pmd_mlx4 causes DPDK to be linked against libibverbs.

-Features and limitations
-
+Features
+-

 - RSS, also known as RCA, is supported. In this mode the number of
   configured RX queues must be a power of two.
@@ -91,11 +91,17 @@ Features and limitations
 - Scattered packets are supported for TX and RX.
 - Inner L3/L4 (IP, TCP and UDP) TX/RX checksum offloading and validation.
 - Outer L3 (IP) TX/RX checksum offloading and validation for VXLAN frames.
+- Secondary process TX is supported.

-.. break
+Limitations
+---

 - RSS hash key cannot be modified.
+- RSS RETA cannot be configured
+- RSS always includes L3 (IPv4/IPv6) and L4 (UDP/TCP). They cannot be
+  dissociated.
 - Hardware counters are not implemented (they are software counters).
+- Secondary process RX is not supported

 Configuration
 -
@@ -237,8 +243,9 @@ DPDK and must be installed separately:

 Currently supported by DPDK:

-- Mellanox OFED **3.0**.
-- Firmware version **2.34.5000** and higher.
+- Mellanox OFED **3.1**.
+- Firmware version **2.35.5100** and higher.
+- Supported architectures:  **x86_64** and **POWER8**.

 Getting Mellanox OFED
 ~
@@ -272,6 +279,13 @@ devices managed by librte_pmd_mlx4.

   modprobe -a ib_uverbs mlx4_en mlx4_core mlx4_ib

+   Alternatively if MLNX_OFED is fully installed, the follwoing script can
+   be run:
+
+   .. code-block:: console
+
+  /etc/init.d/openibd restart
+
.. note::

   User space I/O kernel modules (uio and igb_uio) are not used and do
-- 
1.7.8.2

[dpdk-dev] [PATCH] mlx5: update documentation

[Olga Shern]

- Update features, limitations, configuration and prerequisites sections.
- Add a note to describe RSS behavior differences with librte_pmd_mlx4 in
  testpmd.

Signed-off-by: Olga Shern 
Signed-off-by: Adrien Mazarguil 
---
 doc/guides/nics/mlx5.rst |   67 +++--
 1 files changed, 58 insertions(+), 9 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index eb8c042..1f700fc 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -78,19 +78,23 @@ Features

 - Multiple TX and RX queues.
 - Support for scattered TX and RX frames.
-- IPv4, TCPv4 and UDPv4 RSS on any number of queues.
+- IPv4, IPv6, TCPv4, TCPv6, UDPv4 and UDPv6 RSS on any number of queues.
 - Several RSS hash keys, one for each flow type.
+- Configurable RETA table.
 - Support for multiple MAC addresses.
 - VLAN filtering.
 - Promiscuous mode.
+- Multicast promiscuous mode.
+- Hardware checksum offloads.

 Limitations
 ---

-- IPv6 and inner VXLAN RSS are not supported yet.
+- KVM and VMware ESX SR-IOV modes are not supported yet.
+- Inner RSS for VXLAN frames is not supported yet.
 - Port statistics through software counters only.
-- No allmulticast mode.
-- Hardware checksum offloads are not supported yet.
+- Hardware checksum offloads for VXLAN inner header are not supported yet.
+- Secondary processes are not supported yet.

 Configuration
 -
@@ -119,8 +123,13 @@ These options can be modified in the ``.config`` file.

 - ``CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE`` (default **0**)

-  Amount of data to be inlined during TX operations. Improves latency but
-  lowers throughput.
+  Amount of data to be inlined during TX operations. Improves latency.
+  Can improve PPS performance when PCI backpressure is detected and may be
+  useful for scenarios involving heavy traffic on many queues.
+
+  Since the additional software logic necessary to handle this mode can
+  lower performance when there is no backpressure, it is not enabled by
+  default.

 - ``CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE`` (default **8**)

@@ -205,10 +214,26 @@ DPDK and must be installed separately:

 Currently supported by DPDK:

-- Mellanox OFED **3.1**.
+- Mellanox OFED **3.1-1.0.3** or **3.1-1.5.7.1** depending on usage.
+
+The following features are supported with version **3.1-1.5.7.1** and
+above only:
+
+- IPv6, UPDv6, TCPv6 RSS.
+- RX checksum offloads.
+- IBM POWER8.
+
 - Minimum firmware version:
-  - ConnectX-4: **12.12.0780**.
-  - ConnectX-4 Lx: **14.12.0780**.
+
+  With MLNX_OFED **3.1-1.0.3**:
+
+  - ConnectX-4: **12.12.1240**
+  - ConnectX-4 Lx: **14.12.1100**
+
+  With MLNX_OFED **3.1-1.5.7.1**:
+
+  - ConnectX-4: **12.13.0144**
+  - ConnectX-4 Lx: **14.13.0144**

 Getting Mellanox OFED
 ~
@@ -230,6 +255,23 @@ required from that distribution.
this DPDK release was developed and tested against is strongly
recommended. Please check the `prerequisites`_.

+Notes for testpmd
+-
+
+Compared to librte_pmd_mlx4 that implements a single RSS configuration per
+port, librte_pmd_mlx5 supports per-protocol RSS configuration.
+
+Since ``testpmd`` defaults to IP RSS mode and there is currently no
+command-line parameter to enable additional protocols (UDP and TCP as well
+as IP), the following commands must be entered from its CLI to get the same
+behavior as librte_pmd_mlx4:
+
+.. code-block:: console
+
+   > port stop all
+   > port config all rss all
+   > port start all
+
 Usage example
 -

@@ -242,6 +284,13 @@ devices managed by librte_pmd_mlx5.

   modprobe -a ib_uverbs mlx5_core mlx5_ib

+   Alternatively if MLNX_OFED is fully installed, the follwoing script can
+   be run:
+
+   .. code-block:: console
+
+  /etc/init.d/openibd restart
+
.. note::

   User space I/O kernel modules (uio and igb_uio) are not used and do
-- 
1.7.8.2

[dpdk-dev] [PATCH 0/2] *** Updated release_2_2.rst with mlx4 and mlx5 information ***

[Olga Shern]

*** BLURB HERE ***

Olga Shern (2):
  release_2_2.rst: add mlx4 new features and bug fixes
  release_2_2.rst: add mlx4 and mlx5 known issues

 doc/guides/rel_notes/release_2_2.rst |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)

-- 
1.7.8.2

[dpdk-dev] [PATCH 1/2] release_2_2.rst: add mlx4 new features and bug fixes

[Olga Shern]

Signed-off-by: Olga Shern 
---
 doc/guides/rel_notes/release_2_2.rst |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 591f4cc..c3ff086 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -108,6 +108,10 @@ New Features
   Like mlx4, this PMD is only available for Linux and is disabled by default
   due to external dependencies (libibverbs and libmlx5).

+* **Added support for link status interrupts in mlx4.**
+
+* **Added partial support (TX only) for secondary processes in mlx4.**
+
 * **Added driver for Netronome nfp-6xxx card.**

   Support for using Netronome nfp-6xxx with PCI VFs.
@@ -217,6 +221,16 @@ Drivers
   The mlx drivers were unable to load when built as a shared library,
   due to a missing symbol in mempool library.

+* **mlx4: Performance improvements.**
+
+  Fixed bugs in TX and RX flows that improves mlx4 perfromance.
+
+* **mlx4: Fixed Tx loss after initialization.**
+
+* **mlx4:  Fixed scattered Tx with too many segments.**
+
+* **mlx4: Fixed memory registration for indirect mbuf data.**
+
 * **vhost: Fixed Qemu shutdown.**

   Fixed issue with libvirt ``virsh destroy`` not killing the VM.
-- 
1.7.8.2

[dpdk-dev] [PATCH 2/2] release_2_2.rst: add mlx4 and mlx5 known issues

[Olga Shern]

Signed-off-by: Olga Shern 
---
 doc/guides/rel_notes/release_2_2.rst |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index c3ff086..4f393cf 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -284,6 +284,19 @@ Known Issues
   As the l3fwd example application requires this info, the i40e vector
   driver must be disabled to benefit of the packet type with i40e.

+* **Mellanox PMDs (mlx4 & mlx5):**
+
+  * PMDs do not support DPDK integrated shared library.
+
+  * There is performance degradation for small packets when PMD
+is compiled with SGE_WR_N = 4 compared to the performance when SGE_WR_N = 
1.
+If scattered packets are not used it is recomended
+to compile PMD with SGE_WR_N = 1.
+
+  **mlx4:**
+
+  * When a Multicast or Broadcast packet is sent to the SR-IOV VF,
+it is returned back to the port.

 API Changes
 ---
-- 
1.7.8.2

[dpdk-dev] Compilation error on Power8 with RC3

[Olga Shern]

Hi Pablo, 

Thanks, looks that this is fixed indeed with latest code.

Best Regards,
Olga

-Original Message-
From: De Lara Guarch, Pablo [mailto:pablo.de.lara.gua...@intel.com] 
Sent: Thursday, December 10, 2015 11:36 AM
To: Olga Shern ; dev at dpdk.org
Subject: RE: Compilation error on Power8 with RC3

Hi Olga,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olga Shern
> Sent: Thursday, December 10, 2015 9:08 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Compilation error on Power8 with RC3
> 
> Hi,
> 
> We see the following compilation error on Power8,  Ubuntu15.04 with
> DPDK2.2 RC3:
> 
> 
> In file included from /download/dpdk/app/test/test_hash_scaling.c:35:0:
> /download/dpdk/ppc_64-power8-linuxapp-gcc/include/rte_hash.h:70:70:
> error: unknown type name 'size_t'
> typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2, 
> size_t key_len);
>   
> ^
> /download/dpdk/ppc_64-power8-linuxapp-gcc/include/rte_hash.h:120:48:
> error: unknown type name 'rte_hash_cmp_eq_t'
> void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t 
> func);
> ^
> /download/dpdk/mk/internal/rte.compile-pre.mk:126: recipe for target 
> 'test_hash_scaling.o' failed
> make[5]: *** [test_hash_scaling.o] Error 1
> /download/dpdk/mk/rte.subdir.mk:61: recipe for target 'test' failed
> make[4]: *** [test] Error 2
> /download/dpdk/mk/rte.sdkbuild.mk:77: recipe for target 'app' failed
> make[3]: *** [app] Error 2
> /download/dpdk/mk/rte.sdkroot.mk:123: recipe for target 'all' failed
> make[2]: *** [all] Error 2
> /download/dpdk/mk/rte.sdkinstall.mk:84: recipe for target 'pre_install'
> failed
> make[1]: *** [pre_install] Error 2
> /download/dpdk/mk/rte.sdkroot.mk:98: recipe for target 'install' 
> failed
> make: *** [install] Error 2
> 
> Best Regards,
> Olga
> 
> 

I thought this was fixed in http://dpdk.org/dev/patchwork/patch/9422/.

Thanks,
Pablo

[dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size

[Olga Shern]

Acked-by: Olga Shern 

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Monday, December 14, 2015 4:13 PM
To: Mcnamara, John 
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer 
size

2015-11-10 17:29, Mcnamara, John:
> From: Nelio Laranjeiro [mailto:nelio.laranjeiro at 6wind.com]
> > Current buffer size are not enough for a few testpmd commands.
> > 
> > Signed-off-by: Nelio Laranjeiro 
> 
> Acked-by: John McNamara 

Acked-by: Thomas Monjalon 

[dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration

[Olga Shern]

Acked-by: Olga Shern 

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Monday, December 14, 2015 4:25 PM
To: Nelio Laranjeiro 
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA 
configuration

2015-11-09 17:48, Nelio Laranjeiro:
> +* ABI changes is planned for the reta field in struct 
> rte_eth_rss_reta_entry64
> +  which handles at most 256 entries (8 bits) while newer NICs support larger
> +  tables (512 entries).
> +  It should be integrated in release 2.3.

Acked-by: Thomas Monjalon 

[dpdk-dev] [PATCH] doc: fix typos and inaccuracies (mlx4/mlx5)

[Olga Shern]

Signed-off-by: Olga Shern 
---
 doc/guides/nics/mlx4.rst |   10 +-
 doc/guides/nics/mlx5.rst |4 ++--
 doc/guides/rel_notes/release_2_2.rst |   12 ++--
 3 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index 62f0c31..7757013 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -31,8 +31,8 @@ MLX4 poll mode driver library
 =

 The MLX4 poll mode driver library (**librte_pmd_mlx4**) implements support
-for **Mellanox ConnectX-3 EN** 10/40 Gbps adapters as well as their virtual
-functions (VF) in SR-IOV context.
+for **Mellanox ConnectX-3** and **Mellanox ConnectX-3 Pro** 10/40 Gbps adapters
+as well as their virtual functions (VF) in SR-IOV context.

 Information and documentation about this family of adapters can be found on
 the `Mellanox website <http://www.mellanox.com>`_. Help is also provided by
@@ -79,7 +79,7 @@ long as they share the same MAC address.
 Compiling librte_pmd_mlx4 causes DPDK to be linked against libibverbs.

 Features
--
+

 - RSS, also known as RCA, is supported. In this mode the number of
   configured RX queues must be a power of two.
@@ -101,7 +101,7 @@ Limitations
 - RSS always includes L3 (IPv4/IPv6) and L4 (UDP/TCP). They cannot be
   dissociated.
 - Hardware counters are not implemented (they are software counters).
-- Secondary process RX is not supported
+- Secondary process RX is not supported.

 Configuration
 -
@@ -279,7 +279,7 @@ devices managed by librte_pmd_mlx4.

   modprobe -a ib_uverbs mlx4_en mlx4_core mlx4_ib

-   Alternatively if MLNX_OFED is fully installed, the follwoing script can
+   Alternatively if MLNX_OFED is fully installed, the following script can
be run:

.. code-block:: console
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 1f700fc..b2a12ce 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -31,7 +31,7 @@ MLX5 poll mode driver
 =

 The MLX5 poll mode driver library (**librte_pmd_mlx5**) provides support for
-**Mellanox ConnectX-4 EN** and **Mellanox ConnectX-4 Lx EN** families of
+**Mellanox ConnectX-4** and **Mellanox ConnectX-4 Lx** families of
 10/25/40/50/100 Gb/s adapters as well as their virtual functions (VF) in
 SR-IOV context.

@@ -284,7 +284,7 @@ devices managed by librte_pmd_mlx5.

   modprobe -a ib_uverbs mlx5_core mlx5_ib

-   Alternatively if MLNX_OFED is fully installed, the follwoing script can
+   Alternatively if MLNX_OFED is fully installed, the following script can
be run:

.. code-block:: console
diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index c0f3be2..458ce8f 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -390,7 +390,7 @@ Drivers

 * **mlx4: Fixed Tx loss after initialization.**

-* **mlx4:  Fixed scattered Tx with too many segments.**
+* **mlx4: Fixed scattered Tx with too many segments.**

 * **mlx4: Fixed memory registration for indirect mbuf data.**

@@ -455,9 +455,12 @@ Known Issues
   PF reset in host side. The workaround is to avoid triggering any PF reset
   events/requests on host side.

+* 100G link report support is missing.
+
 * **Mellanox PMDs (mlx4 & mlx5):**

-  * PMDs do not support DPDK integrated shared library.
+  * PMDs do not support CONFIG_RTE_BUILD_COMBINE_LIBS and
+CONFIG_RTE_BUILD_SHARED_LIB simultaneously.

   * There is performance degradation for small packets when PMD
 is compiled with SGE_WR_N = 4 compared to the performance when SGE_WR_N = 
1.
@@ -467,6 +470,11 @@ Known Issues
   * When a Multicast or Broadcast packet is sent to the SR-IOV mlx4 VF,
 it is returned back to the port.

+  * PMDs report "bad" L4 checksum when IP packet is recieved.
+
+  * mlx5 PMD reports "bad" checksum although the packet has "good" checksum.
+Will be fixed in upcoming MLNX_OFED release.
+

 API Changes
 ---
-- 
1.7.8.2

[dpdk-dev] [PATCH] doc: announce ABI change for link speed

[Olga Shern]

Acked-by: Olga Shern 

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Tuesday, December 15, 2015 9:21 AM
To: dev at dpdk.org
Cc: Marc Sune ; Olga Shern ; 
Matej Vido 
Subject: [PATCH] doc: announce ABI change for link speed

A rework was prepared by Marc Sune:
http://dpdk.org/ml/archives/dev/2015-October/026037.html
The goal is to retrieve the supported link speed of a device and to allow 100G 
devices while having a consistent API.

Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index a4abb08..f8a41dd 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -12,6 +12,9 @@ Deprecation Notices
   ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
   tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff

+* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
+  must be updated to support 100G link and to have a cleaner link speed API.
+
 * ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
   which handles at most 256 entries (8 bits) while newer NICs support larger
   tables (512 entries).
--
2.5.2

[dpdk-dev] [PATCH v6 0/5] ethdev: add speed capabilities and refactor link API

[Olga Shern]

We will test on Mellanox NICs

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marc Sune
Sent: Wednesday, December 16, 2015 10:38 PM
To: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v6 0/5] ethdev: add speed capabilities and 
refactor link API

2015-10-25 22:59 GMT+01:00 Marc Sune :

> The current rte_eth_dev_info abstraction does not provide any 
> mechanism to get the supported speed(s) of an ethdev.
>
> For some drivers (e.g. ixgbe), an educated guess could be done based 
> on the driver's name (driver_name in rte_eth_dev_info), see:
>
> http://dpdk.org/ml/archives/dev/2013-August/000412.html
>
> However, i) doing string comparisons is annoying, and can silently 
> break existing applications if PMDs change their names ii) it does not 
> provide all the supported capabilities of the ethdev iii) for some 
> drivers it is impossible determine correctly the (max) speed by the 
> application (e.g. in i40, distinguish between XL710 and X710).
>
> In addition, the link APIs do not allow to define a set of advertised 
> link speeds for autonegociation.
>
> This series of patches adds the following capabilities:
>
> * speed_capa bitmap in rte_eth_dev_info, which is filled by the PMDs
>   according to the physical device capabilities.
> * refactors link API in ethdev to allow the definition of the advertised
>   link speeds, fix speed (no auto-negociation) or advertise all supported
>   speeds (default).
>
> WARNING: this patch series, specifically 3/4, is NOT tested for most 
> of the PMDs, due to the lack of hardware. Only generic EM is tested (VM).
> Minor bugs expected.
>

I will respin this patch to current HEAD targeting 2.3, but note that testing 
of PMDs other than i40 and e1000 (82540Em) is necessary for this patch to be 
merged.

I do not have all the HW to test it, so I would like to ask for some help here. 
Some (more) peer reviews would also help.

Regards
marc


>
> * * * * *
>
> v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment 
> (checkpatch).
>
> v3: rebase to v2.1. unified ETH_LINK_SPEED and ETH_SPEED_CAP into 
> ETH_SPEED.
> Converted field speed in struct rte_eth_conf to speed, to allow a 
> bitmap
> for defining the announced speeds, as suggested M. Brorup. Fixed 
> spelling
> issues.
>
> v4: fixed errata in the documentation of field speeds of rte_eth_conf, and
> commit 1/2 message. rebased to v2.1.0. v3 was incorrectly based on
> ~2.1.0-rc1.
>
> v5: revert to v2 speed capabilities patch. Fixed MLX4 speed capabilities
> (thanks N. Laranjeiro). Refactored link speed API to allow setting
> advertised speeds (3/4). Added NO_AUTONEG option to explicitely disable
> auto-negociation. Updated 2.2 rel. notes (4/4). Rebased to current 
> HEAD.
>
> v6: Move link_duplex to be part of bitfield. Fixed i40 autoneg flag link
> update code. Added rte_eth_speed_to_bm_flag() to .map file. Fixed other
> spelling issues. Rebased to current HEAD.
>
> Marc Sune (5):
>   ethdev: Added ETH_SPEED_CAP bitmap for ports
>   ethdev: Fill speed capability bitmaps in the PMDs
>   ethdev: redesign link speed config API
>   doc: update with link changes
>   ethdev: add rte_eth_speed_to_bm_flag() to ver. map
>
>  app/test-pmd/cmdline.c | 124
> +++--
>  app/test/virtual_pmd.c |   4 +-
>  doc/guides/rel_notes/release_2_2.rst   |  23 ++
>  drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
>  drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
>  drivers/net/cxgbe/base/t4_hw.c |   8 +-
>  drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
>  drivers/net/e1000/base/e1000_82541.c   |   8 +-
>  drivers/net/e1000/base/e1000_82543.c   |   4 +-
>  drivers/net/e1000/base/e1000_82575.c   |  11 +--
>  drivers/net/e1000/base/e1000_api.c |   2 +-
>  drivers/net/e1000/base/e1000_api.h |   2 +-
>  drivers/net/e1000/base/e1000_defines.h |   4 +-
>  drivers/net/e1000/base/e1000_hw.h  |   2 +-
>  drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
>  drivers/net/e1000/base/e1000_mac.c |   9 ++-
>  drivers/net/e1000/base/e1000_mac.h |   6 +-
>  drivers/net/e1000/base/e1000_vf.c  |   4 +-
>  drivers/net/e1000/base/e1000_vf.h  |   2 +-
>  drivers/net/e1000/em_ethdev.c  | 109 -
>  drivers/net/e1000/igb_ethdev.c | 104 +---
>  drivers/net/fm10k/fm10k_ethdev.c   |   5 +-
>  drivers/net/i40e/i40e_ethdev.c |  78 ++
>  drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
>  drivers/net/ixgbe/ixgbe_ethdev.c   |  74 -
>  drivers/net/mlx4/mlx4.c|   6 ++
>  drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
>  drivers/net/null/rte_eth_null.c|   5 +-
>  drivers/net/pcap/rte_eth_pcap.c|   9 ++-
>  drivers/net/ring/rte_eth_ring.c   

Re: [dpdk-dev] DPDK on IBM Power9

[Olga Shern]

Daniel, 

What exactly is not working for you?
Mellanox is testing Power9  for 19.02 release.

Thanks,
Olga


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Thursday, January 10, 2019 2:08 AM
To: Daniel Waddington 
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] DPDK on IBM Power9

Hi,

09/01/2019 23:25, Daniel Waddington:
> Hi,
> I'm trying to run DPDK 18.11 on IBM Power9.  Should it run?  (I'n new to DPDK 
> on Power).

As mentioned in the release notes, Power9 is supported:

https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdoc.dpdk.org%2Fguides%2Frel_notes%2Frelease_18_11.html%23known-issues&data=02%7C01%7Colgas%40mellanox.com%7C6c8d43623a0348adae1408d6768fb1b1%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636826756880461285&sdata=WzB%2Fz2zsUUZUawHT1W42BPI2M%2FfDu943xNgDI4w90lU%3D&reserved=0

We are missing a strong support from IBM.
Several requests were already sent.
Given your email address, you should be able to forward the need ;)

[dpdk-dev] Mellanox Roadmap for 18.08

[Olga Shern]

Hello all,

Mellanox Roadmap for 18.08 is the following:

Generic Flow API:

* Adding actions for VLAN push/pop for flow API, implementation in mlx5 
PMD enabling full HW offload.

* Extending encapsulation API for MPLS tunnel type offload with 
ConnectX-5.

* Extend flow pattern to match on metadata
mlx5 PMD:

* support port representors (also known as "VF representors").

* support RTE_FLOW_ACTION_TYPE_PORT_ID  action and PORT_ID flow item 
using full HW offload.

* support VXLAN encap/decap for ConnectX-5 and BlueField SmartNIC.

* support several flow priorities.

* BlueField SmartNIC GA support, enabling running DPDK on SmartNIC ARM 
cores and/or Host cores with DPDK representors.

* support 32bit compilation

* Some enhancements for Multi-Packet Receive Queue.
mlx4 PMD

* support TSO HW offload for ConnectX-3  Pro.

* support 32bit compilation
TAP & FailSafe PMDs

* support secondary-process in TAP and FailSafe PMDs.

* Support TSO  for TAP PMD
Best Regards,
Olga

-------
Olga Shern
SW Sr. Director DPDK
Mellanox Technologies, Raanana, Israel

Re: [dpdk-dev] mellanox connectx-2 support

[Olga Shern]

Vasily, 

ConnectX-2 is very, very old card.
We don't support it. 
You can run DPDK on ConnectX-3 Pro, ConnectX-4 /LX and ConnectX-5 NICs.
The best performance and better feature set you will get with ConnectX-5 

Best Regards,
Olga


---
Olga Shern
SW Sr. Director DPDK 
Mellanox Technologies, Raanana, Israel 



-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Vasiliy Tolstov
Sent: Thursday, May 17, 2018 2:01 AM
To: dev@dpdk.org
Subject: [dpdk-dev] mellanox connectx-2 support

Hello. I have some mellanox (ConnectX-2 ?) cards (MT26428) does it possible to 
use it with dpdk? Why dpdk supports only X-4 and X-5  cards?
Thanks!

--
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

Re: [dpdk-dev] mellanox connectx-2 support

[Olga Shern]

You can use rdma over Ethernet, AKA ROCE
Mellanox PMDs  don't  need vfio 
I am not sure what you are trying to achieve, you want  to run DPDK on 
Infiniband?

-Original Message-
From: Vasiliy Tolstov [mailto:v.tols...@selfip.ru] 
Sent: Tuesday, May 22, 2018 12:10 AM
To: Adrien Mazarguil 
Cc: Василий Толстов ; Olga Shern ; 
dev@dpdk.org
Subject: Re: [dpdk-dev] mellanox connectx-2 support

пн, 21 мая 2018 г. в 12:15, Adrien Mazarguil :

> On Sun, May 20, 2018 at 10:25:01PM +0300, Vasiliy Tolstov wrote:
> > чт, 17 мая 2018 г. в 9:02, Olga Shern :
> >
> > > Vasily,
> > >
> > > ConnectX-2 is very, very old card.
> > > We don't support it.
> > > You can run DPDK on ConnectX-3 Pro, ConnectX-4 /LX and ConnectX-5
NICs.
> > > The best performance and better feature set you will get with
ConnectX-5
> > >
> > > Best Regards,
> > >
> >
> > Thanks for info, web page says about connect-x3 (without pro) If i 
> > have
> > Connect-X3 vpi does it works with intel dpdk mellanox driver?

> Probably, provided both an up-to-date firmware version and that ports
accept
> Ethernet mode configuration [1].

> [1] 
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpdk
> .org%2Fdoc%2Fguides%2Fnics%2Fmlx4.html%23quick-start-guide&data=02%7C0
> 1%7Colgas%40mellanox.com%7C01c4e02666044c162d9a08d5bf5f4090%7Ca652971c
> 7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636625338186508009&sdata=doQaWNjEiS
> RhR28TmbS8iGB22oGfnl%2BDVm78fw%2FJTMQ%3D&reserved=0

=( Bad news, i need to use rdma to transfer storage traffic and not want to 
change ports to ethernet.
Does dpdk can work with vfio ?

--
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

[dpdk-dev] Mellanox roadmap for DPDK 19.05

[Olga Shern]

Below are the features that we are planning for 19.05 release:


  *   New steering flow engine in mlx5 PMD to reach insertion rate of millions 
of rules per sec
  *   FailSafe secondary process support
  *   Introduce DMA memory mapping APIs for external memory
  *   rte_flow API with mlx5 PMD implementation for TCP SEQ and ACK offloading.
  *   rte_flow API with mlx5 PMD implementation for ICMP ping offloading.
  *   New documentation for device management and devargs string
  *   Complete new devargs syntax implementation for networking devices
  *   Out of the box performance improvements for mlx5 PMD by consolidating 
several TX functions to single one.
  *   Improve mlx5 and mlx4 PMDs datapath robustness for Tx and Rx errors.


Best Regards,
Olga

---
Olga Shern
SW Sr. Director DPDK
Mellanox Technologies, Raanana, Israel

[dpdk-dev] [PATCH 0/2] Native uio-based PMD for Mellanox ConnectX-3 devices

[Olga Shern]

Hi Keunhong, 

I disagree with you regarding the performance of ConnectX-3 PMD driver based on 
verbs. We get line rate of 40G link with message size smaller than 512B.
In MLNX_OFED 3.0 we have presented a new verbs, called accelerated verbs, these 
verbs improves by more than 100% the performance of RAW QP for DPDK.  The PMD 
changes based on this new infrastructure have been submitted to this list and 
are  part of DPDK 2.1 release.
Our approach is to improve performance of userspace verbs then to maintain a 
huge amount of code that you have submitted.

Another advantage to use userspace  verbs API is  that you have so called 
bi-furcated driver by design. Kernel driver can work side by side with DPDK PMD 
, if needed, and there is no security issues with this model.

Best Regards,
Olga



Olga Shern 
Sr. Manager, Acceleration libraries team (Accelio, DPDK, VMA) 
Mellanox Technologies, Raanana Israel



-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Keunhong Lee
Sent: Monday, July 06, 2015 8:56 PM
To: Thomas Monjalon
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/2] Native uio-based PMD for Mellanox 
ConnectX-3 devices

We found that optimizing fragmentation configuration of mlx4 driver performs as 
fast as native PMD.
I think we have to re-consider using native driver rather than ib driver.

Keunhong.

2015-07-07 1:14 GMT+09:00 Thomas Monjalon :

> 2015-07-07 00:57, Keunhong Lee:
> > Answer 1. UIO based driver is faster then ib based driver.
> > It can saturate 40G link with MTU sized packets using a single 
> > thread
> while
> > ib wrapper cannot.
>
> OK, interesting. Do you have numbers and details about your 
> testbed/scenario?
>
> > Answer 2. Sorry, I missed that. I'll make a new patch email with my 
> > real name.
> >
> > Question 1. Is it OK if I separate GPL-based and BSD-based codes 
> > into separated patches?
> > mlx4 kernel driver itself is dual licenses, so I think they are
> considered
> > as BSD in my source code.
> > The only source code under GPL is bitmap, integer logarithm, and
> red-black
> > tree contained in mlnx_uio/kernel directory.
>
> These parts will be built in the user-space driver library, right?
> It would change the license, which is not desirable.
>
> Technically, your approach may be interesting.
> But from a maintenance point of view, this huge codebase may be a 
> nightmare.
>
>
> > 2015-07-06 23:17 GMT+09:00 Thomas Monjalon :
> >
> > > 2015-07-06 22:28, leeopop:
> > > > This is a native UIO-based PMD for Mellanox ConnectX-3 devices.
> > > > It uses a persistent memory library in order to provide a 
> > > > persistent scartch area for the mlx4 HCA driver.
> > >
> > > What is the benefit of this UIO approach compared to the OFED 
> > > based
> driver?
> > >
> > > > We release the driver itself under BSD license, but to use it 
> > > > for commercial products, you may have to re-implement the 
> > > > separated GPL sources.
> > >
> > > The GPL sources are not really separated.
> > > The DPDK libraries must be BSD-licensed.
> > >
> > > > The GPL affected source codes reside in the mlnx_uio/kernel
> directory.
> > >
> > > It seems that a large part of the GPL driver was also copied in 
> > > mlnx_uio/mlnx/.
> > >
> > > Given that you are dropping a huge GPL codebase (whose you don't 
> > > own
> the
> > > copyright) in a BSD library, and that you didn't give your real 
> > > name in the signed-off line, it is NACK.
>
>
>
>

[dpdk-dev] [PATCH 0/2] Native uio-based PMD for Mellanox ConnectX-3 devices

[Olga Shern]

Hi Pavel, 

A new Mellanox NIC, ConnectX-4  can achieve line arte with 64b packet for 40G 
link
We will have PMD that supports this NIC in DPDK 2.2 .
By the way, this is also an advantage of using verbs API, with almost 0% effort 
we can support a new NIC 

Best Regards,
Olga

-Original Message-
From: Pavel Odintsov [mailto:pavel.odint...@gmail.com] 
Sent: Tuesday, July 07, 2015 10:02 AM
To: Olga Shern
Cc: Keunhong Lee; Thomas Monjalon; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/2] Native uio-based PMD for Mellanox 
ConnectX-3 devices

Hello!

Sorry for off topic. But this question is very important for me.

Olga, could I achieve line rate with Mellanox Cards with 64b packets for 40GE?

On Tue, Jul 7, 2015 at 9:50 AM, Olga Shern  wrote:
> Hi Keunhong,
>
> I disagree with you regarding the performance of ConnectX-3 PMD driver based 
> on verbs. We get line rate of 40G link with message size smaller than 512B.
> In MLNX_OFED 3.0 we have presented a new verbs, called accelerated verbs, 
> these verbs improves by more than 100% the performance of RAW QP for DPDK.  
> The PMD changes based on this new infrastructure have been submitted to this 
> list and are  part of DPDK 2.1 release.
> Our approach is to improve performance of userspace verbs then to maintain a 
> huge amount of code that you have submitted.
>
> Another advantage to use userspace  verbs API is  that you have so called 
> bi-furcated driver by design. Kernel driver can work side by side with DPDK 
> PMD , if needed, and there is no security issues with this model.
>
> Best Regards,
> Olga
>
>
> ________
> Olga Shern
> Sr. Manager, Acceleration libraries team (Accelio, DPDK, VMA) Mellanox 
> Technologies, Raanana Israel
>
>
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Keunhong Lee
> Sent: Monday, July 06, 2015 8:56 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/2] Native uio-based PMD for Mellanox 
> ConnectX-3 devices
>
> We found that optimizing fragmentation configuration of mlx4 driver performs 
> as fast as native PMD.
> I think we have to re-consider using native driver rather than ib driver.
>
> Keunhong.
>
> 2015-07-07 1:14 GMT+09:00 Thomas Monjalon :
>
>> 2015-07-07 00:57, Keunhong Lee:
>> > Answer 1. UIO based driver is faster then ib based driver.
>> > It can saturate 40G link with MTU sized packets using a single 
>> > thread
>> while
>> > ib wrapper cannot.
>>
>> OK, interesting. Do you have numbers and details about your 
>> testbed/scenario?
>>
>> > Answer 2. Sorry, I missed that. I'll make a new patch email with my 
>> > real name.
>> >
>> > Question 1. Is it OK if I separate GPL-based and BSD-based codes 
>> > into separated patches?
>> > mlx4 kernel driver itself is dual licenses, so I think they are
>> considered
>> > as BSD in my source code.
>> > The only source code under GPL is bitmap, integer logarithm, and
>> red-black
>> > tree contained in mlnx_uio/kernel directory.
>>
>> These parts will be built in the user-space driver library, right?
>> It would change the license, which is not desirable.
>>
>> Technically, your approach may be interesting.
>> But from a maintenance point of view, this huge codebase may be a 
>> nightmare.
>>
>>
>> > 2015-07-06 23:17 GMT+09:00 Thomas Monjalon :
>> >
>> > > 2015-07-06 22:28, leeopop:
>> > > > This is a native UIO-based PMD for Mellanox ConnectX-3 devices.
>> > > > It uses a persistent memory library in order to provide a 
>> > > > persistent scartch area for the mlx4 HCA driver.
>> > >
>> > > What is the benefit of this UIO approach compared to the OFED 
>> > > based
>> driver?
>> > >
>> > > > We release the driver itself under BSD license, but to use it 
>> > > > for commercial products, you may have to re-implement the 
>> > > > separated GPL sources.
>> > >
>> > > The GPL sources are not really separated.
>> > > The DPDK libraries must be BSD-licensed.
>> > >
>> > > > The GPL affected source codes reside in the mlnx_uio/kernel
>> directory.
>> > >
>> > > It seems that a large part of the GPL driver was also copied in 
>> > > mlnx_uio/mlnx/.
>> > >
>> > > Given that you are dropping a huge GPL codebase (whose you don't 
>> > > own
>> the
>> > > copyright) in a BSD library, and that you didn't give your real 
>> > > name in the signed-off line, it is NACK.
>>
>>
>>
>>



--
Sincerely yours, Pavel Odintsov

Re: [dpdk-dev] Mellanox 100GbE MCX516A-CCAT

[Olga Shern]

Hi  Yasuhiro,

Please contact Mellanox support and open a case , supp...@mellanox.com 

Best Regards,
Olga

---
Olga Shern
SW Sr. Director DPDK 
Mellanox Technologies, Raanana, Israel 



-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yasuhiro Ohara
Sent: Saturday, April 14, 2018 9:26 AM
To: dev@dpdk.org
Subject: [dpdk-dev] Mellanox 100GbE MCX516A-CCAT


Hi,

I am trying to use Mellanox MCX516A-CCAT in DPDK.
ConnectX-5 EN network interface card, 100GbE dual-port QSFP28,
PCIe3.0 x16, tall bracket, ROHS R6

I noticed it is not supported yet,
(<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdpdk.org%2Fdoc%2Fguides%2Fnics%2Fmlx5.html&data=02%7C01%7Colgas%40mellanox.com%7Ccccbb71d1eb746f841d608d5a1d090e6%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636592839568352566&sdata=KffKaTX1hmahlN0xoI9Enes2r0s%2F%2BjiO8OLonU%2B0ANg%3D&reserved=0>)
but how far is it ?

If I setup mlx5 for MCX516A-CCAT, I get these errors.

PMD: net_mlx5: Forcing port 9 link to be up
PMD: net_mlx5: 0x7ff83ffaae00: error occurred while configuring control flows: 
Invalid argument
WARNING: port[9]: rte_eth_dev_start() failed: error: -11.

I guess this is -EAGAIN from below.
rte_ethdev.c: rte_eth_dev_start():
1026 diag = (*dev->dev_ops->dev_start)(dev);
mlx5_trigger.c: mlx5_dev_start():
170 err = priv_force_link_status_change(priv, ETH_LINK_UP);

My configuration:
dpdk-17.11.1.tar.xz
MLNX_OFED_LINUX-4.2-1.2.0.0 (--upstream-libs)
fw_ver: 16.22.1002

Initial log messages:
EAL: PCI device :af:00.1 on NUMA socket 1
EAL:   probe driver: 15b3:1017 net_mlx5
PMD: mlx5.c:615: mlx5_pci_probe(): PCI information matches, using device 
"mlx5_9" (SR-IOV: false)
PMD: mlx5.c:660: mlx5_pci_probe(): 1 port(s) detected
PMD: mlx5.c:860: mlx5_pci_probe(): Enhanced MPS is enabled
PMD: mlx5.c:887: mlx5_pci_probe(): port 1 MAC address is 50:6b:4b:08:6c:77

If I enable CONFIG_RTE_LIBRTE_MLX5_DEBUG=y, I get the following crash from an 
assertion.

dpdk-stable-17.11.1/drivers/net/mlx5/mlx5_trigger.c:283: 
priv_dev_traffic_enable: Assertion `(mlx5_ctrl_flow(dev, &multicast, 
&multicast)) == 0' failed.

Thread 1 "progname" received signal SIGABRT, Aborted.
0x766c9428 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x766c9428 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x766cb02a in __GI_abort () at abort.c:89
#2  0x766c1bd7 in __assert_fail_base (fmt=, 
assertion=assertion@entry=0x824ec0 "(mlx5_ctrl_flow(dev, &multicast, 
&multicast)) == 0", 
file=file@entry=0x824c68 
"/home/hspcr/dpdk-stable-17.11.1/drivers/net/mlx5/mlx5_trigger.c", 
line=line@entry=283, 
function=function@entry=0x824f30 <__PRETTY_FUNCTION__.38015> 
"priv_dev_traffic_enable") at assert.c:92
#3  0x766c1c82 in __GI___assert_fail (
assertion=assertion@entry=0x824ec0 "(mlx5_ctrl_flow(dev, &multicast, 
&multicast)) == 0", 
file=file@entry=0x824c68 
"/home/hspcr/dpdk-stable-17.11.1/drivers/net/mlx5/mlx5_trigger.c", 
line=line@entry=283, 
function=function@entry=0x824f30 <__PRETTY_FUNCTION__.38015> 
"priv_dev_traffic_enable") at assert.c:101
#4  0x006db033 in priv_dev_traffic_enable (
priv=priv@entry=0x7ff83ffea940, dev=dev@entry=0xd1b580 )
at /home/hspcr/dpdk-stable-17.11.1/drivers/net/mlx5/mlx5_trigger.c:283
#5  0x006db1aa in priv_link_start (priv=priv@entry=0x7ff83ffea940)
at /home/hspcr/dpdk-stable-17.11.1/drivers/net/mlx5/mlx5_ethdev.c:915
#6  0x006dc780 in priv_link_update (priv=priv@entry=0x7ff83ffea940, 
wait_to_complete=wait_to_complete@entry=0)
at /home/hspcr/dpdk-stable-17.11.1/drivers/net/mlx5/mlx5_ethdev.c:969
#7  0x006dded9 in priv_force_link_status_change (
priv=priv@entry=0x7ff83ffea940, status=status@entry=1)
at /home/hspcr/dpdk-stable-17.11.1/drivers/net/mlx5/mlx5_ethdev.c:1000
#8  0x006da92d in mlx5_dev_start (dev=0xd1b580 )
at /home/hspcr/dpdk-stable-17.11.1/drivers/net/mlx5/mlx5_trigger.c:170
#9  0x0051dfbd in rte_eth_dev_start ()

Mellanox(R) ConnectX(R)-4 100G MCX416A-CCAT (2x100G) seems to be working, by 
the way, in the same configuration.

Thanks for help in advance.

Best regards,
Yasu

[dpdk-dev] Mellanox 18.05 roadmap

[Olga Shern]

Hi,

Sorry for sending it a little bit late.
Below is what we are planning to implement in 18.05 release:

Support Rx stateless ethdev offloads (RSS, checksum and packet type 
classification) for various tunnel protocols. Including VXLAN, VXLAN-GPE, 
MPLSoGRE and MPLSoUDP.
This new API will be implemented in mlx5.


Support Tx stateless ethdev offloads (TSO and checksum) for custom tunnel 
protocols.  Custom tunnel protocol is defined by informing the PMD on the 
offsets and header types of the inner and outer headers inside the packet 
payload.
This new API will be implemented in mlx5.



API to support full HW offload including:

Redirecting specific flows from one VM to another VM without SW processing.

Manipulation of packet payload including encap/decap of headers, vlan push/pop, 
headers rewrite, etc



Defining , in collaboration with Intel,  API for VF representors  and  control 
API to configure VF from host.



Participating in new devargs  syntax development, which is bus agnostic  and   
separate generic and driver specific properties.



rte_flow support for bonding PMD.



TSO support for TAP PMD.



mlx5 and mlx4 support  new dynamic memory allocation suggested by the series: 
http://dpdk.org/ml/archives/dev/2018-March/092070.html.



mlx5 and mlx4 support non-contiguous memory pools.



mlx5 performance improvements:

   - stride RQ to reach  100G with 64B message

   - OOB performance




---
Olga Shern
SW Director DPDK
Mellanox Technologies, Raanana, Israel

Re: [dpdk-dev] Mellanox ConnectX-5 crashes and mbuf leak

[Olga Shern]

Hi Martin, 

We will look into this issue and will try to reproduce.
Will update you as soon as we have any news.

Can you please send kernel crush stack that you are seeing.

Best Regards,
Olga


Olga Shern 
SW Director DPDK 
Mellanox Technologies, Raanana Israel



> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Martin Weiser
> Sent: Tuesday, September 26, 2017 12:24 PM
> To: Adrien Mazarguil ; Nélio Laranjeiro
> 
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] Mellanox ConnectX-5 crashes and mbuf leak
> 
> Hi,
> 
> we are currently testing the Mellanox ConnectX-5 100G NIC with DPDK
> 17.08 as well as dpdk-net-next and are
> experiencing mbuf leaks as well as crashes (and in some instances even
> kernel panics in a mlx5 module) under certain load conditions.
> 
> We initially saw these issues only in our own DPDK-based application and it
> took some effort to reproduce this in one of the DPDK example applications.
> However with the attached patch to the load-balancer example we can
> reproduce the issues reliably.
> 
> The patch may look weird at first but I will explain why I made these
> changes:
> 
> * the sleep introduced in the worker threads simulates heavy processing
> which causes the software rx rings to fill
>   up under load. If the rings are large enough (I increased the ring size with
> the load-balancer command line option
>   as you can see in the example call further down) the mbuf pool may run
> empty and I believe this leads to a malfunction
>   in the mlx5 driver. As soon as this happens the NIC will stop forwarding
> traffic, probably because the driver
>   cannot allocate mbufs for the packets received by the NIC.
> Unfortunately when this happens most of the mbufs will
>   never return to the mbuf pool so that even when the traffic stops the pool
> will remain almost empty and the
>   application will not forward traffic even at a very low rate.
> 
> * the use of the reference count in the mbuf in addition to the situation
> described above is what makes the
>   mlx5 DPDK driver crash almost immediately under load. In our application
> we rely on this feature to be able to forward
>   the packet quickly and still send the packet to a worker thread for analysis
> and finally free the packet when analysis is
>   done. Here I simulated this by increasing the mbuf reference count
> immediately after receiving the mbuf from the
>   driver and then calling rte_pktmbuf_free in the worker thread which should
> only decrement the reference count again
>   and not actually free the mbuf.
> 
> We executed the patched load-balancer application with the following
> command line:
> 
>     ./build/load_balancer -l 3-7 -n 4 -- --rx "(0,0,3),(1,0,3)" --tx 
> "(0,3),(1,3)" --w
> "4" --lpm "16.0.0.0/8=>0; 48.0.0.0/8=>1;" --pos-lb 29 --rsz "1024, 32768, 
> 1024,
> 1024"
> 
> Then we generated traffic using the t-rex traffic generator and the sfr test
> case. On our machine the issues start to happen when the traffic exceeds ~6
> Gbps but this may vary depending on how powerful the test machine is (by
> the way we were able to reproduce this on different types of hardware).
> 
> A typical stacktrace looks like this:
> 
>     Thread 1 "load_balancer" received signal SIGSEGV, Segmentation fault.
>     0x00614475 in _mm_storeu_si128 (__B=..., __P= out>) at /usr/lib/gcc/x86_64-linux-gnu/5/include/emmintrin.h:716
>     716      __builtin_ia32_storedqu ((char *)__P, (__v16qi)__B);
>     (gdb) bt
>     #0  0x00614475 in _mm_storeu_si128 (__B=..., __P= out>) at /usr/lib/gcc/x86_64-linux-gnu/5/include/emmintrin.h:716
>     #1  rxq_cq_decompress_v (elts=0x7fff3732bef0, cq=0x77f99380,
> rxq=0x7fff3732a980) at
> /root/dpdk-next-net/drivers/net/mlx5/mlx5_rxtx_vec_sse.c:679
>     #2  rxq_burst_v (pkts_n=, pkts=0xa7c7b0 ,
> rxq=0x7fff3732a980) at
> /root/dpdk-next-net/drivers/net/mlx5/mlx5_rxtx_vec_sse.c:1242
>     #3  mlx5_rx_burst_vec (dpdk_rxq=0x7fff3732a980, pkts= out>, pkts_n=) at
> /root/dpdk-next-net/drivers/net/mlx5/mlx5_rxtx_vec_sse.c:1277
>     #4  0x0043c11d in rte_eth_rx_burst (nb_pkts=3599,
> rx_pkts=0xa7c7b0 , queue_id=0, port_id=0 '\000')
>     at
> /root/dpdk-next-net//x86_64-native-linuxapp-
> gcc/include/rte_ethdev.h:2781
>     #5  app_lcore_io_rx (lp=lp@entry=0xa7c700 ,
> n_workers=n_workers@entry=1, bsz_rd=bsz_rd@entry=144,
> bsz_wr=bsz_wr@entry=144, pos_lb=pos_lb@entry=29 '\035')
>     at /root/dpdk-next-net/examples/load_balancer/runtime.c:198
>     #6  0x00447dc0 in app_lcore_main_loop_io () at
> /root/dpdk-ne

Re: [dpdk-dev] [PATCH v1 0/7] net/mlx5: add vectorized Rx/Tx burst for ARM

[Olga Shern]

> >
> > next-net-mlx sound like good idea :) Any comment on this?
> I agree on your idea!
> 

Yes, Ferruh, let's do it for the next release 

Best Regards,
Olga 

Re: [dpdk-dev] [PATCH v4] doc: update mlx5 flow count limitations

[Olga Shern]

Hi Ferruh,

MLNX_OFED 4.2 will be released by the end of October

Best Regards,
Olga


> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Thursday, October 19, 2017 9:19 AM
> To: Ori Kam ; Adrien Mazarguil
> ; Nélio Laranjeiro
> ; Yongseok Koh ;
> john.mcnam...@intel.com
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4] doc: update mlx5 flow count limitations
> 
> On 10/18/2017 11:09 PM, Ori Kam wrote:
> > Signed-off-by: Ori Kam 
> > Acked-by: Shahaf Shuler 
> > ---
> > v4:
> > * Clarify which OFED versionis required.
> >
> > v3:
> > * Remove unnecessary line.
> >
> >  doc/guides/nics/mlx5.rst | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> > d24941a..bcc39f6 100644
> > --- a/doc/guides/nics/mlx5.rst
> > +++ b/doc/guides/nics/mlx5.rst
> > @@ -104,7 +104,8 @@ Limitations
> >  ---
> >
> >  - Inner RSS for VXLAN frames is not supported yet.
> > -- Port statistics through software counters only.
> > +- Port statistics through software counters only. Flow statistics are
> > +  supported by hardware counters.
> >  - Hardware checksum RX offloads for VXLAN inner header are not
> supported yet.
> >  - Forked secondary process not supported.
> >  - Flow pattern without any specific vlan will match for vlan packets as 
> > well:
> > @@ -127,6 +128,7 @@ Limitations
> >  - A multi segment packet must have less than 6 segments in case the Tx
> burst function
> >is set to multi-packet send or Enhanced multi-packet send. Otherwise it
> must have
> >less than 50 segments.
> > +- Count action for RTE flow is only supported in Mellanox OFED 4.2.
> 
> Is 4.2 become public?
> 
> >
> >  Configuration
> >  -
> >

[dpdk-dev] Multi Queue Support With Mellanox 40GbE NIC - MT27500 Family [ConnectX-3]

[Olga Shern]

Hi Suresh, 

RSS configuration is not supported with  ConnectX-3 PMD.
We added this support for ConnectX-4 PMD, available in DPDK 2.2.

Best Regards,
Olga 

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Suresh Paruchuri
Sent: Tuesday, March 01, 2016 8:03 PM
To: users at dpdk.org; dev at dpdk.org
Subject: [dpdk-dev] Multi Queue Support With Mellanox 40GbE NIC - MT27500 
Family [ConnectX-3]

Hi,
   We are planning to use the Multi Queue features of Mellanox NIC by using RSS 
to distribute packets among the multiple RX queues.  We have Mellanox 
ConnectX-3 NIC.
Seems there are lot of limitations in using RSS as there is no support for Hash 
Key and function update with ConnectX-3 series. Is there any patch available 
for Mellanox to using RSS by required hash update?

Here is the requirement:

1.  Multi Queue Support

2.  Symmetric IP Hash - SRC IP and DST IP


Please guide me if you have any solution available which will help us in using 
Mellanox NIC with multi queue feature. Thanks in advance.

DPDK Version: 2.1.0 + Additional patches.

NIC And Driver Details:
Network controller: Mellanox Technologies MT27500 Family [ConnectX-3]

[root at localhost ~]# ethtool -i p2p1
driver: mlx4_en
version: 3.1-1.0.3 (29 Sep 2015)
firmware-version: 2.34.5000
bus-info: :84:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes
[root at localhost ~]#


Regards,
Suresh.

[dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir

[Olga Shern]

I think what Thomas meant is that we should redesign  Flow Director feature and 
call it something else , Mellanox is calling  it "Flow Steering"  . I agree 
that  Filtering may be more generic name.
We have implemented Flow Director API in Mellanox ConnectX-4 PMD (part of the 
DPDK 16.04 patches) but  we did is in very awkward way that will fit the 
current API and some Mellanox features are missing with current Flow Director 
API.
Therefore I disagree with Jingjing's statement that this API is generic. 
Frankly, it is very hard to understand it , as Thomas mentioned  ..., not sure 
how DPDK users understand what each function/field means  

Best Regards,
Olga

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wu, Jingjing
Sent: Friday, February 26, 2016 3:18 AM
To: Thomas Monjalon; Rahul Lakkireddy
Cc: dev at dpdk.org; Kumar A S; Nirranjan Kirubaharan
Subject: Re: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new 
behavior switch to fdir



> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, February 26, 2016 2:25 AM
> To: Rahul Lakkireddy 
> Cc: Richardson, Bruce ; dev at dpdk.org; 
> Kumar A S ; Nirranjan Kirubaharan 
> ; Wu, Jingjing 
> Subject: Re: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and 
> new behavior switch to fdir
> 
> 2016-02-25 15:03, Rahul Lakkireddy:
> > On Wednesday, February 02/24/16, 2016 at 14:17:58 -0800, Thomas Monjalon 
> > wrote:
> > > > A raw flow provides a generic way for vendors to add their 
> > > > vendor specific input flow.
> > >
> > > Please, "generic" and "vendor specific" in the same sentence.
> > > It's obviously wrong.
> >
> > I think this sentence is being mis-interpreted.
> > What I intended to say is: the fields are generic so that any vendor 
> > can hook-in. The fields themselves are not vendor specific.
> 
> We are trying to push some features into fields of an API instead of 
> thinking how to make it simple.
> 
> > > > In our case, it is possible to match several flows in a single 
> > > > rule.  For example, it's possible to set an ethernet, vlan, ip 
> > > > and tcp/udp flows all in a single rule.  We can specify all of 
> > > > these flows in a single raw input flow, which can then be passed 
> > > > to cxgbe flow director to set the corresponding filter.
> > >
> > > I feel we need to define what is an API.
> > > If the application wants to call something specific to the NIC, 
> > > why using the ethdev API? You just have to include cxgbe.h.
> >
> > Well, in that sense, flow-director is also very intel specific, no ?
> 
> Yes. I think the term "flow director" comes from Intel.
> 
> > What we are trying to do is make flow-director generic
> 
> So let's stop calling it flow director.
> We are talking about filtering, right?
> 
Hi Thomas

Are you suggesting chelsio to define a new filter type?

> Why is it so complex? We are talking about packet filtering, not rocket 
> science!
>
The complex is due to different NICs different behavior :-) As I know, it is a 
common way to use used-define data pass specific infor to driver.

Even flow director is concept from Intel's NIC, but I think it is the generic 
one comparing with other kinds of filters. So I think that's why Rahul choose 
it to add their kind of filters.
As I know enic driver also uses flow director API to support their filters.

No matter chelsio NIC filter uses flow director API or define another new 
filter type. I vote the change happened in struct rte_eth_fdir_input, it 
provide a RAW Flow type, And there is also a mask field for that, by this way, 
user can have a flexible way to configure.
And drivers can parse the raw input to define the filter fields.

But for the change happened in struct rte_eth_fdir_action, only SWITCH type is 
added, Where to switch? All things is in 
behavior_arg[RTE_ETH_BEHAVIOR_ARG_MAX_LEN]
which is black to user. Maybe your previous define in RFC makes more sense. 
It's better to add user defined field but not for all args.

Any better suggestion?

[dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and MLNX_OFED-3.1-1.0.3

[Olga Shern]

Hi Bill, 

There shouldn?t be any problem with what you are doing.
We are checking this now.

Best Regards,
Olga

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bill O'Hara
Sent: Thursday, October 08, 2015 6:05 AM
To: dev at dpdk.org
Subject: [dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and MLNX_OFED-3.1-1.0.3

Hello

I wonder if anyone can suggest why previously working dpdk code may fail in the 
Mellanox pmd code in dpdk-2.1.0, seemingly due to failure to create a "resource 
domain" via ibv_exp_create_res_domain(). I must admit I haven't seen that verb 
before, and it appears to be returning null with no error message.

The DPDK log gives these hints:

PMD: librte_pmd_mlx4: 0xa4fc20: TX queues number update: 0 -> 1
PMD: librte_pmd_mlx4: 0xa4fc20: RX queues number update: 0 -> 1
PMD: librte_pmd_mlx4: 0xa4fc20: RD creation failure: Cannot allocate memory

I'm using dpdk-2.10.0 and  MLNX_OFED_LINUX-3.1-1.0.3 on ubuntu14.04 with a
connectx-3 card.

thanks
bill

[dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and MLNX_OFED-3.1-1.0.3

[Olga Shern]

Hi Bill,

Can you please check the fw version that is installed on your ConnectX3?

Thanks


Sent from Samsung Mobile.


 Original message 
From: Olga Shern
Date:08/10/2015 7:55 AM (GMT+00:00)
To: Bill O'Hara ,dev at dpdk.org
Subject: RE: [dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and 
MLNX_OFED-3.1-1.0.3

Hi Bill,

There shouldn?t be any problem with what you are doing.
We are checking this now.

Best Regards,
Olga

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bill O'Hara
Sent: Thursday, October 08, 2015 6:05 AM
To: dev at dpdk.org
Subject: [dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and MLNX_OFED-3.1-1.0.3

Hello

I wonder if anyone can suggest why previously working dpdk code may fail in the 
Mellanox pmd code in dpdk-2.1.0, seemingly due to failure to create a "resource 
domain" via ibv_exp_create_res_domain(). I must admit I haven't seen that verb 
before, and it appears to be returning null with no error message.

The DPDK log gives these hints:

PMD: librte_pmd_mlx4: 0xa4fc20: TX queues number update: 0 -> 1
PMD: librte_pmd_mlx4: 0xa4fc20: RX queues number update: 0 -> 1
PMD: librte_pmd_mlx4: 0xa4fc20: RD creation failure: Cannot allocate memory

I'm using dpdk-2.10.0 and  MLNX_OFED_LINUX-3.1-1.0.3 on ubuntu14.04 with a
connectx-3 card.

thanks
bill

[dpdk-dev] Segmentation fault when bonding ports on Mellanox ConnectX-3

[Olga Shern]

Hi Jesper,

Bonding pmd is not supported with dpdk 2.1 on Mellanox nic
We just sent patches to support async link events. Without these patches it 
will  not work.

Best Regards
Olga
Sent from Samsung Mobile.


 Original message 
From: Jesper Wramberg
Date:08/10/2015 4:25 PM (GMT+00:00)
To: dev at dpdk.org
Subject: [dpdk-dev] Segmentation fault when bonding ports on Mellanox ConnectX-3

Hi all,

I was wondering if anyone has any experience with the ConnectX-3 card from
Mellanox ? I have a server with such a card I can't seem to get link
bonding to work.

I've installed the necessary kernel modules, etc. and the card works as
expected when testing it using e.g. the layer 2 forwarding example. If i
try to run the bond example, however, I get a segmentation fault when the
"rte_eth_bond_slave_add" function is called. Originally I wanted to bond
the ports using the EAL cmd line option but the card only has one pci
address :(

Does anyone have any idea what could be causing this behavior ?
I am running fw version 2.30.x which I have considered upgrading. Besides
this I have been wondering if I have to do anything in Linux since the PMD
uses the Linux drivers for control. I haven't been able to find any
information on it though.

Regards,
Jesper Wramberg

[dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and MLNX_OFED-3.1-1.0.3

[Olga Shern]

Hi Bill,

Starting from DPDK 2.1 ConnectX-3 PMD is based on ?accelerated verbs?,  
ibv_exp_create_res_domain is coming from this new API.
Just to make sure I understand what you are doing:  you have enabled SRIOV and 
you are running DPDK on hypervisor on the probed VFs that you have created, 
right?
We did test this combination (dpdk2.1 and ofed3.1-3)on hypervisor on the PF and 
also on VM on VF, but in fact, I didn?t try to run DPDK on the VFs on 
hypervisor, I will check this.
Meanwhile, can you please send the output of the application on the start up.  
Do you see any errors in dmesg?

Best Regards,
Olga

From: Bill O'Hara [mailto:billtoh...@gmail.com]
Sent: Thursday, October 08, 2015 11:55 PM
To: Olga Shern
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and 
MLNX_OFED-3.1-1.0.3

Olga

If it's all all helpful, linking our code against dpdk-2.0 and (statically) 
against the appropriate custom-built libibverbs that we used with it, works on 
those machines. There is of course no call to ibv_exp_create_res_domain() in 
that version of the library. But it at least confirms basic operation of the 
upgraded OFED and firmware on those boxes.

Is there anything else we can check or confirm for you?

thanks
bill


On Thu, Oct 8, 2015 at 9:06 AM, Bill O'Hara mailto:billtohara at gmail.com>> wrote:
Hi Olga

Firmware is version 2.35.5100. Configuration details below.

Thanks for any hints.
bill

root:~# cat /etc/modprobe.d/mlx4_core.conf
options mlx4_core port_type_array=2,2 num_vfs=16 probe_vf=4

root:~# ibstat
CA 'mlx4_0'
CA type: MT4099
Number of ports: 1
Firmware version: 2.35.5100
Hardware version: 1
Node GUID: 0xf4521403008f1680
System image GUID: 0xf4521403008f1683
Port 1:
State: Active
Physical state: LinkUp
Rate: 56
Base lid: 0
LMC: 0
SM lid: 0
Capability mask: 0x0c01
Port GUID: 0xf65214fffe8f1680
Link layer: Ethernet
CA 'mlx4_1'
CA type: MT4100
Number of ports: 1
Firmware version: 2.35.5100
Hardware version: 1
Node GUID: 0x00140500c2d3b05f
System image GUID: 0xf4521403008f1683
Port 1:
State: Active
Physical state: LinkUp
Rate: 56
Base lid: 0
LMC: 0
SM lid: 0
Capability mask: 0x0c01
Port GUID: 0xfc9739fffe1272c3
Link layer: Ethernet
CA 'mlx4_2'
CA type: MT4100
Number of ports: 1
Firmware version: 2.35.5100
Hardware version: 1
Node GUID: 0x00140500b90af10c
System image GUID: 0xf4521403008f1683
Port 1:
State: Active
Physical state: LinkUp
Rate: 56
Base lid: 0
LMC: 0
SM lid: 0
Capability mask: 0x0c01
Port GUID: 0x20ecbbfffeefb934
Link layer: Ethernet
CA 'mlx4_3'
CA type: MT4100
Number of ports: 1
Firmware version: 2.35.5100
Hardware version: 1
Node GUID: 0x001405009661e607
System image GUID: 0xf4521403008f1683
Port 1:
State: Active
Physical state: LinkUp
Rate: 56
Base lid: 0
LMC: 0
SM lid: 0
Capability mask: 0x0c01
Port GUID: 0xf4c8e6fffe5abc89
Link layer: Ethernet
CA 'mlx4_4'
CA type: MT4100
Number of ports: 1
Firmware version: 2.35.5100
Hardware version: 1
Node GUID: 0x00140500bd09e128
System image GUID: 0xf4521403008f1683
Port 1:
State: Active
Physical state: LinkUp
Rate: 56
Base lid: 0
LMC: 0
SM lid: 0
Capability mask: 0x0c01
Port GUID: 0x5828e1fffe34f919
Link layer: Ethernet

On Thu, Oct 8, 2015 at 2:03 AM, Olga Shern mailto:olgas 
at mellanox.com>> wrote:
Hi Bill,

Can you please check the fw version that is installed on your ConnectX3?

Thanks


Sent from Samsung Mobile.

 Original message 
From: Olga Shern
Date:08/10/2015 7:55 AM (GMT+00:00)
To: Bill O'Hara ,dev at dpdk.org<mailto:dev at dpdk.org>
Subject: RE: [dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and 
MLNX_OFED-3.1-1.0.3

Hi Bill,

There shouldn?t be any problem with what you are doing.
We are checking this now.

Best Regards,
Olga

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bill O'Hara
Sent: Thursday, October 08, 2015 6:05 AM
To: dev at dpdk.org<mailto:dev at dpdk.org>
Subject: [dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and MLNX_OFED-3.1-1.0.3

Hello

I wonder if anyone can suggest why previously working dpdk code may fail in the 
Mellanox pmd code in dpdk-2.1.0, seemingly due to failure to create a "resource 
domain" via ibv_exp_create_res_domain(). I must admit I haven't seen that verb 
before, and it appears to be returning null with no error message.

The DPDK log gives these hints:

PMD: librte_pmd_mlx4: 0xa4fc20: TX queues number update: 0 -> 1
PMD: librte_pmd_mlx4: 0xa4fc20: RX queues number update: 0 -> 1
PMD: librte_pmd_mlx4: 0xa4fc20: RD creation failure: Cannot allocate memory

I'm using dpdk-2.10.0 and  MLNX_OFED_LINUX-3.1-1.0.3 on ubuntu14.04 with a
connectx-3 card.

thanks
bill

[dpdk-dev] Segmentation fault when bonding ports on Mellanox ConnectX-3

[Olga Shern]

For the sake of clarity, I assume you mean the patches about:
"eal: new interrupt handler type"
"mlx4: handle interrupts"
[Olga ] Yes, you are right

Best Regards,
Olga

2015-10-08 17:36 GMT+02:00 Olga Shern mailto:olgas at 
mellanox.com>>:


Hi Jesper,

Bonding pmd is not supported with dpdk 2.1 on Mellanox nic
We just sent patches to support async link events. Without these patches it 
will  not work.

Best Regards
Olga
Sent from Samsung Mobile.

 Original message 
From: Jesper Wramberg
Date:08/10/2015 4:25 PM (GMT+00:00)
To: dev at dpdk.org<mailto:dev at dpdk.org>
Subject: [dpdk-dev] Segmentation fault when bonding ports on Mellanox ConnectX-3

Hi all,

I was wondering if anyone has any experience with the ConnectX-3 card from
Mellanox ? I have a server with such a card I can't seem to get link
bonding to work.

I've installed the necessary kernel modules, etc. and the card works as
expected when testing it using e.g. the layer 2 forwarding example. If i
try to run the bond example, however, I get a segmentation fault when the
"rte_eth_bond_slave_add" function is called. Originally I wanted to bond
the ports using the EAL cmd line option but the card only has one pci
address :(

Does anyone have any idea what could be causing this behavior ?
I am running fw version 2.30.x which I have considered upgrading. Besides
this I have been wondering if I have to do anything in Linux since the PMD
uses the Linux drivers for control. I haven't been able to find any
information on it though.

Regards,
Jesper Wramberg

[dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and MLNX_OFED-3.1-1.0.3

[Olga Shern]

Hi Bill,

Sorry it took me a while to reply ?.
We did more tests and didn?t reproduce the issue.
I also checked the code and seems that there are only 2  conditions when RD 
creation fails,

1.   The arguments we are passing to the RD creation function are wrong ? 
this is not reasonable, because this is PMD code and here the behavior is not 
deterministic , works in most cases and doesn?t work on your setup ?

2.   calloc function is failing ? also not reasonable

There is a verb  application that uses accelerated verbs and res domains, 
raw_ethernet_bw
Example:
raw_ethernet_bw -d mlx4_0  -i 1  --client -E 00:00:00:00:01:02 --use_res_domain 
--verb_type=accl

Another suggestion, can you please compile PMD with debug enabled, it may give 
more details ?

Best Regards,
Olga

From: Bill O'Hara [mailto:billtoh...@gmail.com]
Sent: Saturday, October 10, 2015 12:18 AM
To: Olga Shern 
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and 
MLNX_OFED-3.1-1.0.3

Hi Olga

Thanks for the pointer towards the use of "accelerated verbs".

Yes, SRIOV is enabled, dpdk on the hypervisor on the probed VFs. That said, it 
also fails on the underlying PF as far as I see (e.g. below the log shows (VF: 
false) for device mlx4_0 and the code fails in RD creation on this as well as 
on one of the VFs). I don't see any messages generated in dmesg that seem to 
indicate errors at any point, but extract included below.

But here's perhaps the crux! Switching off sriov and running with the new 
combination of dpdk and ofed against just a single PF also fails in exactly the 
same way (RD creation failure).

The old code continues to work. I will audit our code to make sure we're not 
missing something when using dpdk-2.1. In the meantime, do you have a minimal 
test that involves RD creation?

thanks
bill



// DPDK output for application run using dpdk-2.1 and ofed 3.1
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 0 on socket 0
EAL: Detected lcore 7 as core 1 on socket 0
EAL: Detected lcore 8 as core 2 on socket 0
EAL: Detected lcore 9 as core 3 on socket 0
EAL: Detected lcore 10 as core 4 on socket 0
EAL: Detected lcore 11 as core 5 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 12 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0xe40 bytes
EAL: Virtual area found at 0x7fffe600 (size = 0xe40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fffe5c0 (size = 0x20)
EAL: Ask a virtual area of 0x7180 bytes
EAL: Virtual area found at 0x7fff7420 (size = 0x7180)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fff73e0 (size = 0x20)
EAL: Requesting 512 pages of size 2MB from socket 0
EAL: TSC frequency is ~2394453 KHz
EAL: Master lcore 0 is ready (tid=f7fe7940;cpuset=[0])
EAL: lcore 1 is ready (tid=e53fe700;cpuset=[1])
EAL: lcore 2 is ready (tid=e4bfd700;cpuset=[2])
EAL: lcore 3 is ready (tid=e43fc700;cpuset=[3])
EAL: PCI device :01:00.0 on NUMA socket 0
EAL:   probe driver: 15b3:1003 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_0" (VF: false)
PMD: librte_pmd_mlx4: 1 port(s) detected
PMD: librte_pmd_mlx4: port 1 MAC address is f4:52:14:8f:16:80
EAL: PCI device :01:00.1 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_1" (VF: true)
PMD: librte_pmd_mlx4: 1 port(s) detected
PMD: librte_pmd_mlx4: port 1 MAC address is b2:00:7c:2b:3f:47
EAL: PCI device :01:00.2 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_2" (VF: true)
PMD: librte_pmd_mlx4: 1 port(s) detected
PMD: librte_pmd_mlx4: port 1 MAC address is 3a:3d:c7:e0:ed:5a
EAL: PCI device :01:00.3 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_3" (VF: true)
PMD: librte_pmd_mlx4: 1 port(s) detected
PMD: librte_pmd_mlx4: port 1 MAC address is ee:6a:a6:79:24:4c
EAL: PCI device :01:00.4 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_4" (VF: true)
PMD: librte_pmd_mlx4: 1 port(s) detected
PMD: librte_pmd_mlx4: port 1 MAC address is 8a:7a:30:00:46:33
EAL: PCI device :01:00.5 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: cannot access device, is mlx4_ib loaded?
EAL: PCI device :01:00.6 on NUMA socket 0
EA

[dpdk-dev] Segmentation fault when bonding ports on Mellanox ConnectX-3

[Olga Shern]

Hi Jeff,

Glad to hear that this is working for you ?
What bonding mode do you use?

There is a limitation, as you saw, we cannot  add additional MAC to the VF from 
DPDK.
You can set MAC of the VF on VM  by the same way you did on the pf.

Let me know if you have any additional questions

Best Regards,
Olga


From: Jesper Wramberg [mailto:jesper.wramb...@gmail.com]
Sent: Monday, October 12, 2015 7:03 PM
To: Olga Shern 
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Segmentation fault when bonding ports on Mellanox 
ConnectX-3

Hi again,

The patches worked great and the DPDK bonding API functions with the ConnectX-3 
now.. yay :-)

I have run into some new trouble however and since its related I figured I 
would ask here if anyone could help. I am using SR-IOV to create a dual-port 
VF. When trying to bond the ports on this VF it seems that DPDK cannot set the 
mac address on the slaves. As a result, I am unable to receive data on the 
bonded port. As a workaround, I can set the mac address on the two VF ports 
manually in Linux using "ip link set  vf 0 mac ..." after which I 
can start DPDK and receive data on the bonded port as wanted.

Is there a way to allow DPDK to change the mac address so I avoid the 
workaround ? I have done some searching but couldn't find anything.

Regards,
Jesper Wramberg



2015-10-09 0:29 GMT+02:00 Olga Shern mailto:olgas at 
mellanox.com>>:
For the sake of clarity, I assume you mean the patches about:
"eal: new interrupt handler type"
"mlx4: handle interrupts"
[Olga ] Yes, you are right

Best Regards,
Olga

2015-10-08 17:36 GMT+02:00 Olga Shern mailto:olgas at 
mellanox.com>>:


Hi Jesper,

Bonding pmd is not supported with dpdk 2.1 on Mellanox nic
We just sent patches to support async link events. Without these patches it 
will  not work.

Best Regards
Olga
Sent from Samsung Mobile.

 Original message 
From: Jesper Wramberg
Date:08/10/2015 4:25 PM (GMT+00:00)
To: dev at dpdk.org<mailto:dev at dpdk.org>
Subject: [dpdk-dev] Segmentation fault when bonding ports on Mellanox ConnectX-3

Hi all,

I was wondering if anyone has any experience with the ConnectX-3 card from
Mellanox ? I have a server with such a card I can't seem to get link
bonding to work.

I've installed the necessary kernel modules, etc. and the card works as
expected when testing it using e.g. the layer 2 forwarding example. If i
try to run the bond example, however, I get a segmentation fault when the
"rte_eth_bond_slave_add" function is called. Originally I wanted to bond
the ports using the EAL cmd line option but the card only has one pci
address :(

Does anyone have any idea what could be causing this behavior ?
I am running fw version 2.30.x which I have considered upgrading. Besides
this I have been wondering if I have to do anything in Linux since the PMD
uses the Linux drivers for control. I haven't been able to find any
information on it though.

Regards,
Jesper Wramberg

[dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and MLNX_OFED-3.1-1.0.3

[Olga Shern]

Hi Bill,

Glad to hear that everything is working for you ?
Let me know if you have any  question or you have figured out what was wrong 
with your compilation

Best Regards,
Olga

From: Bill O'Hara [mailto:billtoh...@gmail.com]
Sent: Friday, October 16, 2015 10:11 PM
To: Olga Shern 
Cc: dev at dpdk.org; Moshe Lazer 
Subject: Re: [dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and 
MLNX_OFED-3.1-1.0.3

Hi Olga,

Sorry for slow response. Initially, raw_ethernet_bw and raw_ethernet_lat were 
not working.

* we clean installed some boxes, rather than upgrading from previous ofed etc 
and now the raw_ethernet_bw and raw_ethernet_lat work. (This is on ubuntu14.04 
with most recent mellanox ofed release).

* dpdk-2.1 still did not work. We clean installed the build box, to clear any 
possibility of mismatches due to upgrade process. Still not working.

* at the suggestion of one of our developers, we switched from statically 
linking dpdk and libibverbs to static dpdk and dynamic libibverbs. Now the dpdk 
test programs work.

* at this point, we've switched back to our own kernel build (with patches), 
our own dpdk programs, and everything appears to be correct.

Apologies for the firedrill -- we do not yet know the exact root cause, but it 
appears to be related to having done an upgrade of mellanox ofed on the 
ubuntu14.04 boxes AND building with static linking of libibverbs (though we 
double checked that the correct .a file was being linked). I will let you know 
if we have a more satisfactory answer -- we're also more highly prioritizing 
hermetic builds at this point.

thanks for your help and hints!
bill


On Thu, Oct 15, 2015 at 5:50 AM, Olga Shern mailto:olgas 
at mellanox.com>> wrote:
Hi Bill,

Sorry it took me a while to reply ?.
We did more tests and didn?t reproduce the issue.
I also checked the code and seems that there are only 2  conditions when RD 
creation fails,

1.   The arguments we are passing to the RD creation function are wrong ? 
this is not reasonable, because this is PMD code and here the behavior is not 
deterministic , works in most cases and doesn?t work on your setup ?

2.   calloc function is failing ? also not reasonable

There is a verb  application that uses accelerated verbs and res domains, 
raw_ethernet_bw
Example:
raw_ethernet_bw -d mlx4_0  -i 1  --client -E 00:00:00:00:01:02 --use_res_domain 
--verb_type=accl

Another suggestion, can you please compile PMD with debug enabled, it may give 
more details ?

Best Regards,
Olga

From: Bill O'Hara [mailto:billtohara at gmail.com<mailto:billtoh...@gmail.com>]
Sent: Saturday, October 10, 2015 12:18 AM
To: Olga Shern mailto:olgas at mellanox.com>>

Cc: dev at dpdk.org<mailto:dev at dpdk.org>
Subject: Re: [dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and 
MLNX_OFED-3.1-1.0.3

Hi Olga

Thanks for the pointer towards the use of "accelerated verbs".

Yes, SRIOV is enabled, dpdk on the hypervisor on the probed VFs. That said, it 
also fails on the underlying PF as far as I see (e.g. below the log shows (VF: 
false) for device mlx4_0 and the code fails in RD creation on this as well as 
on one of the VFs). I don't see any messages generated in dmesg that seem to 
indicate errors at any point, but extract included below.

But here's perhaps the crux! Switching off sriov and running with the new 
combination of dpdk and ofed against just a single PF also fails in exactly the 
same way (RD creation failure).

The old code continues to work. I will audit our code to make sure we're not 
missing something when using dpdk-2.1. In the meantime, do you have a minimal 
test that involves RD creation?

thanks
bill



// DPDK output for application run using dpdk-2.1 and ofed 3.1
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 0 on socket 0
EAL: Detected lcore 7 as core 1 on socket 0
EAL: Detected lcore 8 as core 2 on socket 0
EAL: Detected lcore 9 as core 3 on socket 0
EAL: Detected lcore 10 as core 4 on socket 0
EAL: Detected lcore 11 as core 5 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 12 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0xe40 bytes
EAL: Virtual area found at 0x7fffe600 (size = 0xe40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fffe5c0 (size = 0x20)
EAL: Ask a virtual area of 0x7180 bytes
EAL: Virtual area found at 0x7fff7420 (size = 0x7180)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fff73e0 (size = 0x20)
EAL: Requesting 512 pages of size 2MB from socket 0
EAL: TSC frequency is ~2394453 KH

[dpdk-dev] Compiling MLX4 Support into 2.1.0

[Olga Shern]

Nathan,

What application are you running?
Please send the output of it.
Please send output of ofed_info  -s, ibdev2netdev and ibv_devinfo. Do you see 
any errors in dmesg?

Regards,
Olga


Sent from Samsung Mobile.


 Original message 
From: Nathan Speulda
Date:11/09/2015 7:51 PM (GMT+02:00)
To: Nathan Speulda ,dev at dpdk.org
Subject: Re: [dpdk-dev] Compiling MLX4 Support into 2.1.0

Thank you for the response,

I followed all of the documentation before I came to the forum on this
one.  OFED is installed and working correctly with all drivers loaded.  I
get to the point of compiling dpdk with support enabled and nothing appears
to come out during the compile (for mlx4 which is included in the
.config).  My interfaces are not being seen by the PMD though I am aware it
works differently than the base supported adapters.

Thanks,
Nathan

On Fri, Sep 11, 2015 at 9:35 AM, Adrien Mazarguil <
adrien.mazarguil at 6wind.com> wrote:

> Hi Nathan,
>
> On Fri, Sep 11, 2015 at 09:10:03AM -0700, Nathan Speulda wrote:
> > All,
> >
> > I am attempting to do some work using a CX3-Pro adapter in a forwarding
> > environment and am attempting to enable the supported PMD that is
> included
> > in the 2.1.0 release of DPDK.  My base distro is RHEL6.5 for stability
> > reasons.  Does anyone have a more detailed idea of how to get the
> Mellanox
> > PMD working correctly?  Does base distro have any impact on this at
> all?  I
> > have been unable to find what I need at the Mellanox community support.
>
> You need to install Mellanox OFED before attempting to compile the mlx4
> PMD, as described in the relevant documentation (doc/guides/nics/mlx4.rst)
> also available here:
>
>  http://dpdk.org/doc/guides/nics/mlx4.html
>
> See "Prerequisites" and "Getting Mellanox OFED" sections.
>
> It should work fine with all Linux distributions supported by Mellanox
> OFED. In your specific case, RHEL 6.5 is supported by MOFED 3.0-2.0.1.
>
> --
> Adrien Mazarguil
> 6WIND
>

[dpdk-dev] DPDK 2.2 roadmap

[Olga Shern]

Hi, 

Mellanox will submit a new PMD for ConnectX-4 and ConnectX-4 LX  cards 

Best Regards,
Olga


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Monday, September 14, 2015 11:57 AM
To: Zhang, Helin; O'Driscoll, Tim
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] DPDK 2.2 roadmap

Thanks for the details.
The roadmap is updated:
http://dpdk.org/dev/roadmap

Maybe the keep-alive feature needs some design discussion.

Anyone else to share his plan?

[dpdk-dev] [PATCH] doc : update guide and release notes for mlx5

[Olga Shern]

Signed-off-by: Olga Shern 
---
 doc/guides/nics/mlx5.rst   |7 ++-
 doc/guides/rel_notes/release_16_07.rst |   16 +++-
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 063c4a5..1bcb818 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -154,6 +154,11 @@ Run-time configuration
   allows to save PCI bandwidth and improve performance at the cost of a
   slightly higher CPU usage.  Enabled by default.

+  Supported on:
+
+  - x86_64 with ConnectX4 and ConnectX4 LX
+  - Power8 with ConnectX4 LX
+
 - ``txq_inline`` parameter [int]

   Amount of data to be inlined during TX operations. Improves latency.
@@ -234,7 +239,7 @@ DPDK and must be installed separately:

 Currently supported by DPDK:

-- Mellanox OFED **3.3-1.0.0.0**.
+- Mellanox OFED **3.3-1.0.0.0** and **3.3-2.0.0.0**

 - Minimum firmware version:

diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index d00a6ed..b48f676 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -191,7 +191,21 @@ New Features

   Live migration of a VM with Virtio and VF PMD's using the bonding PMD.

-
+* **Updated the mlx5 driver.**
+
+  The mlx5 driver was updated with changes including the following:
+
+  * Data path was refactored to bypass Verbs to improve RX and TX performance.
+  * Removed compilation parameters for inline send, MLX5_MAX_INLINE, and
+added command line parameter instead, txq_inline.
+  * Improved TX scatter gather support: 
+Removed compilation parameter MLX5_PMD_SGE_WR_N.
+Scatter-gather elements is set to the maximum value the NIC supports.
+Removed linearization logic, this decreases the memory consumption of the 
PMD.
+  * Improved jumbo frames support, by dynamically setting RX scatter gather 
elements
+according to the MTU and mbuf size,
+no need for compilation parameter MLX5_PMD_SGE_WR_N.
+ 
 Resolved Issues
 ---

-- 
1.7.8.2

[dpdk-dev] [PATCH v2] doc: update guide and release notes for mlx5

[Olga Shern]

Signed-off-by: Olga Shern 
---
 doc/guides/nics/mlx5.rst   |7 ++-
 doc/guides/rel_notes/release_16_07.rst |   14 ++
 2 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 063c4a5..5c10cd3 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -154,6 +154,11 @@ Run-time configuration
   allows to save PCI bandwidth and improve performance at the cost of a
   slightly higher CPU usage.  Enabled by default.

+  Supported on:
+
+  - x86_64 with ConnectX4 and ConnectX4 LX
+  - Power8 with ConnectX4 LX
+
 - ``txq_inline`` parameter [int]

   Amount of data to be inlined during TX operations. Improves latency.
@@ -234,7 +239,7 @@ DPDK and must be installed separately:

 Currently supported by DPDK:

-- Mellanox OFED **3.3-1.0.0.0**.
+- Mellanox OFED **3.3-1.0.0.0** and **3.3-2.0.0.0**.

 - Minimum firmware version:

diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index d00a6ed..4b43f8d 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -191,6 +191,20 @@ New Features

   Live migration of a VM with Virtio and VF PMD's using the bonding PMD.

+* **Updated the mlx5 driver.**
+
+  The mlx5 driver was updated with changes including the following:
+
+  * Data path was refactored to bypass Verbs to improve RX and TX performance.
+  * Removed compilation parameters for inline send, ``MLX5_MAX_INLINE``, and
+added command line parameter instead, ``txq_inline``.
+  * Improved TX scatter gather support:
+Removed compilation parameter ``MLX5_PMD_SGE_WR_N``.
+Scatter-gather elements is set to the maximum value the NIC supports.
+Removed linearization logic, this decreases the memory consumption of the 
PMD.
+  * Improved jumbo frames support, by dynamically setting RX scatter gather 
elements
+according to the MTU and mbuf size,
+no need for compilation parameter ``MLX5_PMD_SGE_WR_N``

 Resolved Issues
 ---
-- 
1.7.8.2

[dpdk-dev] [PATCH] doc : update guide and release notes for mlx5

[Olga Shern]

Thanks John 
Sent fixed patch including your comments 

Best Regards,
Olga


-Original Message-
From: Mcnamara, John [mailto:john.mcnam...@intel.com] 
Sent: Wednesday, July 27, 2016 11:18 AM
To: Olga Shern ; dev at dpdk.org
Subject: RE: [dpdk-dev] [PATCH] doc : update guide and release notes for mlx5



> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olga Shern
> Sent: Tuesday, July 26, 2016 5:29 PM
> To: dev at dpdk.org
> Cc: Olga Shern 
> Subject: [dpdk-dev] [PATCH] doc : update guide and release notes for 
> mlx5
> 
> ...
>
> +* **Updated the mlx5 driver.**
> +
> +  The mlx5 driver was updated with changes including the following:
> +
> +  * Data path was refactored to bypass Verbs to improve RX and TX
> performance.
> +  * Removed compilation parameters for inline send, MLX5_MAX_INLINE, and
> +added command line parameter instead, txq_inline.
> +  * Improved TX scatter gather support:
> +Removed compilation parameter MLX5_PMD_SGE_WR_N.
> +Scatter-gather elements is set to the maximum value the NIC supports.
> +Removed linearization logic, this decreases the memory 
> + consumption of
> the PMD.
> +  * Improved jumbo frames support, by dynamically setting RX scatter
> gather elements
> +according to the MTU and mbuf size,
> +no need for compilation parameter MLX5_PMD_SGE_WR_N.
> +

Hi,

There are 2 whitespace warnings in the patch. If you resubmit can you also put 
the MLX5 variables in  fixed width quotes.

Apart from that:

Acked-by: John McNamara 

[dpdk-dev] Mellanox dpdk issues

[Olga Shern]

Hi Sotiris, 

You can disable compilation of igb_uio, this module is not needed for Mellanox 
PMD.

Let me know if you have any question 

Best Regards,
Olga




-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gilad Berman
Sent: Sunday, November 22, 2015 1:30 PM
To: Sotiris Salloumis ; dev at dpdk.org
Subject: Re: [dpdk-dev] Mellanox dpdk issues

Let us check and get back to you. 


Gilad Berman | Staff System Engineer | Business Development | Mellanox 
Technologies Ltd. 
Work: +972 52 2554262| 6 Ha'Barzel St. Tel Aviv 6971010, Israel


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Sotiris Salloumis
Sent: Friday, November 20, 2015 7:35 PM
To: dev at dpdk.org
Subject: [dpdk-dev] Mellanox dpdk issues

Hi all,

I'm trying to build DPDK for Mellanox ( using MLNX_DPDK-2.1_1.1 ) but I get the 
following error following the guidelines i.e. make install 
T=x86_64-native-linuxapp-gcc

== Build lib/librte_eal/linuxapp/igb_uio
make[8]: *** /lib/modules/3.12.28-4-default/build: No such file or directory.  
Stop.
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.module.mk:79: recipe for target 
'igb_uio.ko' failed
make[7]: *** [igb_uio.ko] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 
'igb_uio' failed
make[6]: *** [igb_uio] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 
'linuxapp' failed
make[5]: *** [linuxapp] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 
'librte_eal' failed
make[4]: *** [librte_eal] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkbuild.mk:93: recipe for target 
'lib' failed
make[3]: *** [lib] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkroot.mk:124: recipe for target 
'all' failed
make[2]: *** [all] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkinstall.mk:58: recipe for target 
'x86_64-native-linuxapp-gcc_install' failed
make[1]: *** [x86_64-native-linuxapp-gcc_install] Error 2
/root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkroot.mk:102: recipe for target 
'install' failed
make: *** [install] Error 2

The environment is SLES12


-  Linux linux-okj7 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 
2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux

-  3.12.28-4-default

>From Mellanox point of view the only difference I see is related with firmware 
>version

 Performing Adapter Device Self Test  Number of CAs Detected 
. 1 PCI Device Check ... PASS Kernel Arch 
 x86_64 Host Driver Version  
MLNX_OFED_LINUX-3.1-1.0.3 (OFED-3.1-1.0.3): 3.12.28-4-default Host Driver RPM 
Check .. PASS Firmware on CA #0 NIC .. 
v2.35.5130 Firmware Check on CA #0 (NIC) .. PASS
NOTE: The found fw version is higher than the fw included in this package 
(v2.35.5100) Host Driver Initialization . PASS Number of CA Ports 
Active .. 2 Port State of Port #1 on CA #0 (NIC). UP 1X QDR 
(Ethernet) Port State of Port #2 on CA #0 (NIC). UP 1X QDR (Ethernet) Error 
Counter Check on CA #0 (NIC).. NA (Eth ports) Kernel Syslog Check 
 PASS Node GUID on CA #0 (NIC) ... 
a0:1d:48:03:00:b5:a6:17
-- DONE -

Any hints?

Thanks
Sotiris

[dpdk-dev] [PATCH v2] hash: rename unused field to "reserved"

[Olga Shern]

Hi, 

I see the following compilation error :
dpdk/lib/librte_hash/rte_cuckoo_hash.c:145: error: flexible array member in 
otherwise empty struct
when compiling on RH6.5

Best Regards,
Olga

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce Richardson
Sent: Monday, July 13, 2015 7:39 PM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v2] hash: rename unused field to "reserved"

The cuckoo hash has a fixed number of entries per bucket, so the configuration 
parameter for this is unused. We change this field in the parameters struct to 
"reserved" to indicate that there is now no such parameter value, while at the 
same time keeping ABI consistency.

Fixes: 48a399119619 ("hash: replace with cuckoo hash implementation")

Suggested-by: Thomas Monjalon 
Signed-off-by: Bruce Richardson 
---
 app/test/test_func_reentrancy.c | 1 -
 app/test/test_hash_perf.c   | 1 -
 app/test/test_hash_scaling.c| 1 -
 drivers/net/enic/enic_clsf.c| 2 --
 examples/l3fwd-power/main.c | 2 --
 examples/l3fwd-vf/main.c| 1 -
 examples/l3fwd/main.c   | 2 --
 lib/librte_hash/rte_hash.h  | 2 +-
 8 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/app/test/test_func_reentrancy.c b/app/test/test_func_reentrancy.c 
index 85504c0..be61773 100644
--- a/app/test/test_func_reentrancy.c
+++ b/app/test/test_func_reentrancy.c
@@ -226,7 +226,6 @@ hash_create_free(__attribute__((unused)) void *arg)
struct rte_hash_parameters hash_params = {
.name = NULL,
.entries = 16,
-   .bucket_entries = 4,
.key_len = 4,
.hash_func = (rte_hash_function)rte_jhash_32b,
.hash_func_init_val = 0,
diff --git a/app/test/test_hash_perf.c b/app/test/test_hash_perf.c index 
e9a522b..a87fc80 100644
--- a/app/test/test_hash_perf.c
+++ b/app/test/test_hash_perf.c
@@ -100,7 +100,6 @@ int32_t positions[KEYS_TO_ADD];
 /* Parameters used for hash table in unit test functions. */  static struct 
rte_hash_parameters ut_params = {
.entries = MAX_ENTRIES,
-   .bucket_entries = BUCKET_SIZE,
.hash_func = rte_jhash,
.hash_func_init_val = 0,
 };
diff --git a/app/test/test_hash_scaling.c b/app/test/test_hash_scaling.c index 
682ae94..39602cb 100644
--- a/app/test/test_hash_scaling.c
+++ b/app/test/test_hash_scaling.c
@@ -129,7 +129,6 @@ test_hash_scaling(int locking_mode)
uint64_t i, key;
struct rte_hash_parameters hash_params = {
.entries = num_iterations*2,
-   .bucket_entries = 16,
.key_len = sizeof(key),
.hash_func = rte_hash_crc,
.hash_func_init_val = 0,
diff --git a/drivers/net/enic/enic_clsf.c b/drivers/net/enic/enic_clsf.c index 
ca12d2d..9c2abfb 100644
--- a/drivers/net/enic/enic_clsf.c
+++ b/drivers/net/enic/enic_clsf.c
@@ -63,7 +63,6 @@

 #define SOCKET_00
 #define ENICPMD_CLSF_HASH_ENTRIES   ENICPMD_FDIR_MAX
-#define ENICPMD_CLSF_BUCKET_ENTRIES 4

 void enic_fdir_stats_get(struct enic *enic, struct rte_eth_fdir_stats *stats)  
{ @@ -245,7 +244,6 @@ int enic_clsf_init(struct enic *enic)
struct rte_hash_parameters hash_params = {
.name = "enicpmd_clsf_hash",
.entries = ENICPMD_CLSF_HASH_ENTRIES,
-   .bucket_entries = ENICPMD_CLSF_BUCKET_ENTRIES,
.key_len = RTE_HASH_KEY_LENGTH_MAX,
.hash_func = DEFAULT_HASH_FUNC,
.hash_func_init_val = 0,
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c index 
d4eba1a..6eb459d 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -1247,7 +1247,6 @@ setup_hash(int socketid)
struct rte_hash_parameters ipv4_l3fwd_hash_params = {
.name = NULL,
.entries = L3FWD_HASH_ENTRIES,
-   .bucket_entries = 4,
.key_len = sizeof(struct ipv4_5tuple),
.hash_func = DEFAULT_HASH_FUNC,
.hash_func_init_val = 0,
@@ -1256,7 +1255,6 @@ setup_hash(int socketid)
struct rte_hash_parameters ipv6_l3fwd_hash_params = {
.name = NULL,
.entries = L3FWD_HASH_ENTRIES,
-   .bucket_entries = 4,
.key_len = sizeof(struct ipv6_5tuple),
.hash_func = DEFAULT_HASH_FUNC,
.hash_func_init_val = 0,
diff --git a/examples/l3fwd-vf/main.c b/examples/l3fwd-vf/main.c index 
ccbb02f..01f610e 100644
--- a/examples/l3fwd-vf/main.c
+++ b/examples/l3fwd-vf/main.c
@@ -251,7 +251,6 @@ static lookup_struct_t *l3fwd_lookup_struct[NB_SOCKETS];  
struct rte_hash_parameters l3fwd_hash_params = {
.name = "l3fwd_hash_0",
.entries = L3FWD_HASH_ENTRIES,
-   .bucket_entries = 4,
.key_len = sizeof(struct ipv4_5tuple),
.hash_func = DEFAULT_HASH_FUNC,
.hash_func_init_val = 0,
diff --git a/examples/l3fwd/main.c b/examples/

Re: [dpdk-dev] checklist for DPDK on Windows

[Olga Shern]

+Eilon 

Thanks,
Olga

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Omar Cardona
Sent: Tuesday, March 19, 2019 10:36 PM
To: Ranjit Menon ; Thomas Monjalon 
; dev@dpdk.org
Cc: Harini Ramakrishnan ; 
anand.ra...@intel.com; pallavi.ka...@intel.com; jeffrey.b.s...@intel.com; 
bruce.richard...@intel.com; step...@networkplumber.org; 
jerin.ja...@caviumnetworks.com; Raslan Darawsheh ; Khoa 
To 
Subject: Re: [dpdk-dev] checklist for DPDK on Windows

+Khoa

-Original Message-
From: Ranjit Menon 
Sent: Tuesday, March 19, 2019 12:34 PM
To: Thomas Monjalon ; dev@dpdk.org
Cc: Harini Ramakrishnan ; Omar Cardona 
; anand.ra...@intel.com; pallavi.ka...@intel.com; 
jeffrey.b.s...@intel.com; bruce.richard...@intel.com; 
step...@networkplumber.org; jerin.ja...@caviumnetworks.com; rasl...@mellanox.com
Subject: Re: [dpdk-dev] checklist for DPDK on Windows

Thomas...
Status below:


On 3/19/2019 2:52 AM, Thomas Monjalon wrote:
> Any feedback?
> Could we try to give a work estimation for these items?
> 
> 15/03/2019 00:04, Thomas Monjalon:
>> Hi,
>>
>> Below is a list of directories, files or functions which we need to 
>> check to make basic DPDK works on Windows.
>> If something is missing, please complete.
>>
>> The goal of this list is to make a status of what is already done, 
>> and plan what should be done next. It will help to share the workload 
>> among all volunteers during the next months.
>>
>> buildtools/pmdinfogen
- not ported to Windows
>> usertools/dpdk-devbind.py
- not ported to Windows
>> drivers/bus/vdev
- not ported to Windows
>> drivers/bus/pci
- ported to Windows in draft repo (using ICC)
>> lib/librte_pci
- ported to Windows in draft repo (using ICC)
>> lib/librte_cmdline
- ported to Windows in draft repo (using ICC)
>> lib/librte_kvargs
- ported to Windows in draft repo (using ICC)
>> lib/librte_ring
- ported to Windows in draft repo (using ICC)
>> lib/librte_mempool
- ported to Windows in draft repo (using ICC)
>> lib/librte_mbuf
- ported to Windows in draft repo (using ICC)
>> lib/librte_net
- ported to Windows in draft repo (using ICC)
>> lib/librte_eal/common/include/rte_errno.h
>> lib/librte_eal/common/include/rte_string_fns.h
>> lib/librte_eal/common/include/rte_lcore.h
>> lib/librte_eal/common/arch/x86/rte_cpuflags.c
>> lib/librte_eal/common/arch/x86/rte_cycles.c
>> lib/librte_eal/common/eal_common_options.c
>> lib/librte_eal/common/eal_common_thread.c
>> lib/librte_eal/common/eal_common_proc.c
- most 'common' [c/h] files ported to Windows in draft repo (using ICC)
>> lib/librte_eal/windows/eal/eal.c
>>  eal_create_runtime_dir()
>>  rte_eal_iopl_init()
- part of file port available in "Helloworld" patch
>> lib/librte_eal/windows/eal/eal_alarm.c
- ported to Windows in draft repo (using ICC)
>> lib/librte_eal/windows/eal/eal_cpuflags.c
- not ported to Windows
>> lib/librte_eal/windows/eal/eal_debug.c
- part of file port available in "Helloworld" patch
>> lib/librte_eal/windows/eal/eal_dev.c
- not ported to Windows
>> lib/librte_eal/windows/eal/eal_interrupts.c
- ported to Windows in draft repo (using ICC)
>> lib/librte_eal/windows/eal/eal_lcore.c
- part of file port available in "Helloworld" patch
>> lib/librte_eal/windows/eal/eal_log.c
- ported to Windows in draft repo (using ICC)
>> lib/librte_eal/windows/eal/eal_memory.c
- ported to Windows in draft repo (using ICC)
>> lib/librte_eal/windows/eal/eal_thread.c
- part of file port available in "Helloworld" patch
>> lib/librte_eal/windows/eal/eal_timer.c
- ported to Windows in draft repo (using ICC)
>>
>> Please check this list and mention what is done or in progress.
>> The best would be to reference some patches or commits to help 
>> progress together as a community, thanks.
> 
> 
> 

[dpdk-dev] [PATCH v8 3/4] ethdev: redesign link speed config API

[Olga Shern]

Hi Marc, 

You can download MLNX_OFED from Mellanox web site:
http://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers

Best Regards,
Olga

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marc
Sent: Monday, February 15, 2016 1:00 PM
To: N?lio Laranjeiro
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v8 3/4] ethdev: redesign link speed config API

On 15 February 2016 at 09:46, N?lio Laranjeiro 
wrote:

> On Sun, Feb 14, 2016 at 11:17:38PM +0100, Marc Sune wrote:
> > This patch redesigns the API to set the link speed/s configure for 
> > an ethernet port. Specifically:
> >
> > - it allows to define a set of advertised speeds for
> >   auto-negociation.
> > - it allows to disable link auto-negociation (single fixed speed).
> > - default: auto-negociate all supported speeds.
> >
> >[...]
> > diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c  
> >index c5688a7..01c3a5c 100644
> > --- a/drivers/net/mlx4/mlx4.c
> > +++ b/drivers/net/mlx4/mlx4.c
> > @@ -4265,8 +4265,8 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, 
> > struct
> rte_eth_dev_info *info)
> >   if (priv_get_ifname(priv, &ifname) == 0)
> >   info->if_index = if_nametoindex(ifname);
> >
> > - info->speed_capa = ETH_SPEED_CAP_10G |ETH_SPEED_CAP_40G |
> > - ETH_SPEED_CAP_56G;
> > + info->speed_capa = ETH_LINK_SPEED_10G |ETH_LINK_SPEED_40G |
> > + ETH_LINK_SPEED_56G;
> >
> >   priv_unlock(priv);
> >  }
> > @@ -4636,6 +4636,8 @@ mlx4_link_update_unlocked(struct rte_eth_dev 
> > *dev,
> int wait_to_complete)
> >   dev_link.link_speed = link_speed;
> >   dev_link.link_duplex = ((edata.duplex == DUPLEX_HALF) ?
> >   ETH_LINK_HALF_DUPLEX :
> ETH_LINK_FULL_DUPLEX);
> > + dev_link.link_autoneg = ~(dev->data->dev_conf.link_speeds &
> > + 
> > + ETH_LINK_SPEED_NO_AUTONEG);
> >   if (memcmp(&dev_link, &dev->data->dev_link, sizeof(dev_link))) {
> >   /* Link status changed. */
> >   dev->data->dev_link = dev_link; [...]
>
> The same modification are missing in mlx5.
>
>
Damn.. are the required closed-source libraries for MLX4/5 available somewhere 
or is there a chance automatic builds can also compile drivers that require 
external dependencies (like this MLX)?

It is very prone to errors having to guess what is going to happen without 
being able to compile these drivers.

Marc

--
> N?lio Laranjeiro
> 6WIND
>

[dpdk-dev] Multi-process model and mlx4 pmd

[Olga Shern]

Hi Bill, 

Some clarification:

On Mellanox web we have released updated PMD that supports DPDK 1.7/1.8.

the primary and secondary multi-process model limitation is missing  in 
http://dpdk.org/doc/guides/nics/mlx4.html
just because we  forgot to mention it.

In general,  there is currently no mlx4 PMD that supports this feature, this is 
current limitation and we plan to add this feature in the future

Best Regards,
Olga


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bill O'Hara
Sent: Wednesday, June 10, 2015 11:33 PM
To: dev at dpdk.org
Subject: [dpdk-dev] Multi-process model and mlx4 pmd

I see from the Mellanox PMD release notes:

http://www.mellanox.com/related-docs/prod_software/Mellanox_ConnectX3_ConnectX3Pro_DPDK_PMD_Release_Notes_v1.7-8_2.8.4.pdf

that the primary and secondary multi-process model is not supported. Though 
it's not noted as a limitation in the DPDK guide here:

http://dpdk.org/doc/guides/nics/mlx4.html

Can anyone shed light on what the source of the limitation is? Is this 
something that can be worked around, or fixed in the driver, or something 
fundamental?

thanks
bill