Re: [dpdk-users] pktgen -**SOLVED** Did not find any ports to use ***

[Sara Gittlin <sara.gittlin@gmail.com>]

Hi
i didnt know that i have to manually bind the pci-devices to uio drivers
before running pktgen. after i did it - everything is fine and working
Regards
-Sara
On Wed, May 29, 2019 at 1:30 PM Sara Gittlin <sara.gittlin@gmail.com> wrote:

> Hi
> I've tried to run on a host - but got the same error
> my pci-devices are :
> ../dpdk/usertools/dpdk-devbind.py -s
>
> Network devices using kernel driver
> ===================================
> 0000:03:00.0 'Ethernet Connection X552/X557-AT 10GBASE-T 15ad' if=eno3
> drv=ixgbe unused=vfio-pci
> 0000:03:00.1 'Ethernet Connection X552/X557-AT 10GBASE-T 15ad' if=eno4
> drv=ixgbe unused=vfio-pci
>
> *******************
> running pktgen
> *******************
> sudo ./app/x86_64-native-linuxapp-gcc/pktgen  -l 0-1 -n 4 --proc-type auto
> --socket-mem 256  -w 0000:03:00.0 -w 0000:03:00.1 \--file-prefix pg \-- -P
> -m "1.0, 2.1"
>
> Copyright (c) <2010-2019>, Intel Corporation. All rights reserved. Powered
> by DPDK
> EAL: Detected 12 lcore(s)
> EAL: Detected 1 NUMA nodes
> EAL: Auto-detected process type: PRIMARY
> EAL: Multi-process socket /var/run/dpdk/pg/mp_socket
> EAL: No available hugepages reported in hugepages-1048576kB
> EAL: Probing VFIO support...
> EAL: VFIO support initialized
> EAL: PCI device 0000:03:00.0 on NUMA socket 0
> EAL:   probe driver: 8086:15ad net_ixgbe
> EAL: PCI device 0000:03:00.1 on NUMA socket 0
> EAL:   probe driver: 8086:15ad net_ixgbe
> Lua 5.3.1  Copyright (C) 1994-2015 Lua.org, PUC-Rio
>
> *** Copyright (c) <2010-2019>, Intel Corporation. All rights reserved.
> *** Pktgen created by: Keith Wiles -- >>> Powered by DPDK <<<
>
> !PANIC!: *** Did not find any ports to use ***
> PANIC in pktgen_config_ports():
> *** Did not find any ports to use ***6:
> [./app/x86_64-native-linuxapp-gcc/pktgen(_start+0x29) [0x483969]]
> 5: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)
> [0x7fb1a10a9830]]
> 4: [./app/x86_64-native-linuxapp-gcc/pktgen(main+0x659) [0x47aba9]]
> 3: [./app/x86_64-native-linuxapp-gcc/pktgen(pktgen_config_ports+0x1560)
> [0x4ae050]]
> 2: [./app/x86_64-native-linuxapp-gcc/pktgen(__rte_panic+0xc3) [0x469d1f]]
> 1: [./app/x86_64-native-linuxapp-gcc/pktgen(rte_dump_stack+0x2b)
> [0x59066b]]
> Aborted (core dumped)
>
>
>
> On Tue, May 28, 2019 at 9:09 PM Sara Gittlin <sara.gittlin@gmail.com>
> wrote:
>
>> Thank you Stephen and Keith
>> trying your suggestions ..
>> Stephen - regarding your PS - I'm really sorry - I did not mean to
>> prioritise  myself - just pasted the error msg. I'll remember your
>> recommendation ..
>> Regards
>> -Sara
>>
>>
>> On Tue, May 28, 2019 at 5:02 PM Stephen Hemminger <
>> stephen@networkplumber.org> wrote:
>>
>>> On Tue, 28 May 2019 08:33:35 +0300
>>> Sara Gittlin <sara.gittlin@gmail.com> wrote:
>>>
>>> > Hello
>>> > According the dpdk release notes - my NIC   - Onboard NIC: *Intel(R)
>>> > X552*/X557-AT
>>> > (2x10G) was tested
>>> >
>>> > Tested Platforms
>>> >
>>> > ----------------
>>> >
>>> >
>>> > #. SuperMicro 1U
>>> >
>>> >
>>> >    - BIOS: 1.0c
>>> >
>>> >    - Processor: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz
>>> >
>>> >
>>> > #. SuperMicro 1U
>>> >
>>> >
>>> >    - BIOS: 1.0a
>>> >
>>> >    - Processor: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz
>>> >
>>> >    *- Onboard NIC: Intel(R) X552/X557-AT (2x10G)*
>>> >
>>> > Thank you
>>> >
>>> > -Sara
>>> >
>>> > On Mon, May 27, 2019 at 5:56 PM Sara Gittlin <sara.gittlin@gmail.com>
>>> wrote:
>>> >
>>> > > Thank you Stephen
>>> > > i can run pktgen on the host  with same 2 VF's
>>> > > Regards
>>> > > -Sara
>>> > >
>>> > >
>>> > > On Mon, May 27, 2019 at 5:52 PM Stephen Hemminger <
>>> > > stephen@networkplumber.org> wrote:
>>> > >
>>> > >> On Mon, 27 May 2019 17:44:17 +0300
>>> > >> Sara Gittlin <sara.gittlin@gmail.com> wrote:
>>> > >>
>>> > >> > Hello ,
>>> > >> > I'm running pktgen on a ubuntu-16.0p4 VM w 3 CPU's,
>>> > >> > I added  2 SRIOV VFs  devices to the VM - and i can see them w
>>> lspci or
>>> > >> > dpdk-devbind --status
>>> > >> > 00:08.0 Ethernet controller: Intel Corporation Ethernet
>>> Connection X552
>>> > >> > Virtual Function
>>> > >> > 00:09.0 Ethernet controller: Intel Corporation Ethernet
>>> Connection X552
>>> > >> > Virtual Function
>>> > >>
>>> > >> Most likely these devices are missing/not supported by DPDK driver.
>>> > >> Look at the numeric id's (lspci -n) and compare them with the list
>>> > >> of pci ids in the driver source.
>>> > >>
>>> > >> In the past with Intel devices it also helped to look at the Linux
>>> > >> kernel driver. Sometimes the missing id's were there and some small
>>> > >> changes to the MAC code was necessary to get them to work.
>>>
>>> Walking backwards from PCI to device.
>>>
>>> 1. The PCI id table for lspci is in /usr/share/misc/pci.ids
>>>    The entry for X552 is:
>>>         15a9  X552 Virtual Function
>>>    Therefore the PCI vendor:device is 8086:15a9
>>>
>>> 4. On Linux this device is under ixgbevf as
>>>
>>> #define IXGBE_DEV_ID_X550EM_X_VF_HV        0x15A9
>>>
>>> static const struct pci_device_id ixgbevf_pci_tbl[] = {
>>>         {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
>>>         {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV), board_82599_vf_hv
>>> },
>>>         {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
>>>         {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV), board_X540_vf_hv },
>>>         {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
>>>         {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV), board_X550_vf_hv },
>>>         {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF), board_X550EM_x_vf
>>> }
>>>         {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_A_VF), board_x550em_a_vf
>>> },
>>>         /* required last entry */
>>>         {0, }
>>> };
>>>
>>>    Conclusion: you are using X552 on Hyper-V.
>>>
>>> 5. In DPDK, similar table is ixgbe_ethdev.
>>>
>>> /*
>>>  * The set of PCI devices this driver supports (for 82599 VF)
>>>  */
>>> static const struct rte_pci_id pci_id_ixgbevf_map[] = {
>>>         { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_VF) },
>>>         { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
>>> IXGBE_DEV_ID_82599_VF_HV) },
>>>         { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_X540_VF) },
>>>         { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_X540_VF_HV)
>>> },
>>>         { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_X550_VF_HV)
>>> },
>>>         { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_X550_VF) },
>>>         { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
>>> IXGBE_DEV_ID_X550EM_A_VF) },
>>>         { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
>>> IXGBE_DEV_ID_X550EM_A_VF_HV) },
>>>         { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
>>> IXGBE_DEV_ID_X550EM_X_VF) },
>>>         { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
>>> IXGBE_DEV_ID_X550EM_X_VF_HV) },
>>>         { .vendor_id = 0, /* sentinel */ },
>>> };
>>>
>>> So the device is supported...
>>>
>>>
>>> A different possibility is that since you are running on Hyper-V (at
>>> least
>>> according to the device ids) is that vdev_netvsc device is trying to
>>> setup tap
>>> failsafe and messing the port numbers around.
>>> Try disabling it by setting this in the config.
>>>
>>> CONFIG_RTE_LIBRTE_VDEV_NETVSC_PMD=n
>>>
>>>
>>>
>>>
>>> PS: Top posting is not preferred on open source mailing lists.
>>>
>>