Re: [dpdk-users] DPDK on Mellanox BlueField Ref Platform

["Jim Vaigl" <jimv@rockbridgesoftware.com>]

A final update on this issue.  Kiran Vedere went above and beyond the
call of duty: he completely reproduced my hardware setup, showed that it
worked using trex to generate similar traffic to mine, and then provided
me with a bundled-up .bfb of his CentOS (with updated kernel) and OFED
install to try so that there would be no configuration stuff for me to
mess up.

Using this, I saw exactly the same crashes I had seen in my setup.
After some thought, I realized the only meaningful difference was that
my traffic generator and IP configuration relied on an MTU size of 9000.
Once I set the MTU size down to 1500, the crashes stopped.

So, the answer is clearly that I'm just not setting up for the larger
MTU size.  I need to start to understand how to get DPDK to manage
that, but the crashing is at least understood now, and I have a way
forward.

Thanks very much to Kiran.

Regards,
--Jim

-----Original Message-----
From: Jim Vaigl [mailto:jimv@rockbridgesoftware.com] 
Sent: Thursday, September 26, 2019 3:47 PM
To: 'Asaf Penso'; 'Stephen Hemminger'
Cc: 'users@dpdk.org'; 'Kiran Vedere'; 'Erez Ferber'; 'Olga Shern'
Subject: RE: [dpdk-users] DPDK on Mellanox BlueField Ref Platform

> From: Asaf Penso [mailto:asafp@mellanox.com] 
> Sent: Thursday, September 26, 2019 7:00 AM
> To: Jim Vaigl; 'Stephen Hemminger'
> Cc: users@dpdk.org; Kiran Vedere; Erez Ferber; Olga Shern
> Subject: RE: [dpdk-users] DPDK on Mellanox BlueField Ref Platform
>
> Hello Jim,
>
> Thanks for your mail.
> In order  for us to have a better resolution please send a mail to our
support team > - support@mellanox.com
> Please provide as much info about the setup, configuration etc as you can.
>
> In parallel, I added Erez Ferber here to assist.
>
> Regards,
> Asaf Penso

Thanks for the kind offer, Asaf.  I'll take this debug effort
off-line with you and Erez and post back to the list here later
with any resolution so everyone can see the result.

By the way, the prior suggestion of using v. 25 of rdma-core
didn't pan out:  the current build script just makes a local
build in a subdirectory off the source tree and there's no
obvious way to integrate it with the MLNX_OFED environment
and the dpdk install.  After resolving package dependencies
to get rdma-core to build from the GitHub repo, I realized
the instructions say this:

  ---
  Building
  This project uses a cmake based build system. Quick start:

  $ bash build.sh
  build/bin will contain the sample programs and build/lib
  will contain the shared libraries. The build is configured
  to run all the programs 'in-place' and cannot be installed.

  NOTE: It is not currently easy to run from the build
  directory, the plugins only load from the system path.
  ---

--Jim

>> -----Original Message-----
>> From: users <users-bounces@dpdk.org> On Behalf Of Jim Vaigl
>> Sent: Tuesday, September 24, 2019 10:11 PM
>> To: 'Stephen Hemminger' <stephen@networkplumber.org>
>> Cc: users@dpdk.org
>> Subject: Re: [dpdk-users] DPDK on Mellanox BlueField Ref Platform
>> 
>> On Tue, 24 Sep 2019 12:31:51 -0400
>> "Jim Vaigl" <jimv@rockbridgesoftware.com> wrote:
>> 
>>>> Since no one has chimed in with any build/install/configure suggestion
>> for
>> >> the
>> >> BlueField, I've spent some time debugging and thought I'd share the
>> results.
>> >> Building the l3fwd example application and running it as the docs
>> suggest,
>> >> when
>> >> I try to send it UDP packets from another machine, it dumps core.
>> >>
>> >> Debugging a bit with gdb and printf, I can see that from inside
>> >> process_packet()
>> >> and processx4_step1() the calls to rte_pktmbuf_mtod() return Nil or
>> >> suspicious
>> >> pointer values (i.e. 0x80).  The sample apps don't guard against NULL
>> >> pointers
>> >> being returned from this rte call, so that's why it's dumping core.
>> >>
>> >> I still think the problem is related to the driver config, but thought
>> this
>> >> might ring a bell for anyone who's had problems like this.
>> >>
>> >> The thing that still bothers me is that rather than seeing what I was
>> >> expecting
>> >> at init based on what the documentation shows:
>> >>     [...]
>> >>     EAL: probe driver: 15b3:1013 librte_pmd_mlx5
>> >>
>> >> ... when rte_eal_init() runs, I'm seeing:
>> >>     [...]
>> >>     EAL:  Selected IOVA mode 'PA'
>> >>     EAL:  Probing VFIO support...
>> >>
>> >> This still seems wrong, and I've verified that specifying the
BlueField
>> >> target ID
>> >> string in the make is causing "CONFIG_RTE_LIBRTE_MLX5_PMD=y" to
>> appear in
>> >> the .config.
>> >>
>> >> Regards,
>> >> --Jim Vaigl
>> >> 614 886 5999
>> >>
>> >>
>> >
>> >From: Stephen Hemminger [mailto:stephen@networkplumber.org]
>> >Sent: Tuesday, September 24, 2019 1:18 PM
>> >To: Jim Vaigl
>> >Cc: users@dpdk.org
>> >
>> >Subject: Re: [dpdk-users] DPDK on Mellanox BlueField Ref Platform
>> >make sure you have latest version of rdma-core installed (v25).
>> >The right version is not in most distros
>> 
>> Great suggestion.  I'm using the rdma-core from the MLNX_OFED 4.6-3.5.8.0
>> install.  I can't figure out how to tell what version that thing
includes,
>> even looking at the source, since there's no version information in the
>> source files, BUT I went to github and downloaded rdma-core v24 and v25
>> and neither diff cleanly with the source RPM that comes in the OFED
>> install.  I don't know yet if it's because this is some different version
>> or if it's because Mellanox has made their own tweaks.
>> 
>> I would hope that the very latest OFED from Mellanox would include an
>> up-to-date and working set of libs/modules, but maybe you're on to
>> something.  It sounds like a risky move, but maybe I'll try just
>> installing rdma-core from github over top of the OFED install.  I have a
>> fear that I'll end up with inconsistent versions, but it's worth a try.
>> 
>> Thanks,
>> --Jim