[dpdk-dev] [dpdk-users] Intel X710 dropping 802.1ad packets?

2016-07-13 Thread Sean Hope (shope)
I sent this to dpdk-users, but maybe dpdk-dev is a better target list?

Thanks,
Sean

>Hello,
>
>I am seeing a problem with receiving 802.1ad packets on an intel X710
>card, running the 16.04 dpdk release. All the 802.1ad packets are silently
>dropped. The port is in promiscuous mode. As far as counters go, ibytes
>are incremented for these packets, but not ipackets. Some of the extended
>stats are incremented as well (the histogram sizes, etc.)
>
>Has anyone else seen this?
>
>Thanks,
>Sean
>
>



[dpdk-dev] ethdev: replacement for rte_pci_dev_ids.h?

2016-04-08 Thread Sean Hope (shope)

>2016-04-07 18:10, Sean Hope:
>> Hello,
>> 
>> I see that rte_pci_dev_ids.h has been removed.
>
>No it has not been removed (yet):
>   
> http://dpdk.org/browse/dpdk/tree/lib/librte_eal/common/include/rte_pci_de
>v_ids.h
>
>> We are using it on our product to get supported device ids.
>> 
>> I understand the desire to move that data out of a central place and
>>into
>> each driver. Any chance that instead of living in a .c file, that each
>> driver could hold it in a .h file so that it could be easily consumed by
>> an external program?
>
>Yes there is a plan to move the PCI ids in the drivers but
>we need to make a tool to retrieve the ids from the ELF files.
>Why do you want to get them from a .h file?

The need for a .h file isn't an absolute, but we have some code that was
using the existing file. If each driver had their Ids in a per-driver .h
file then we just include one h file per driver instead of
rte_pci_dev_ids.h and our tool still works.

Thanks,
Sean



[dpdk-dev] ethdev: replacement for rte_pci_dev_ids.h?

2016-04-07 Thread Sean Hope (shope)
Hello,

I see that rte_pci_dev_ids.h has been removed.

We are using it on our product to get supported device ids.

I understand the desire to move that data out of a central place and into
each driver. Any chance that instead of living in a .c file, that each
driver could hold it in a .h file so that it could be easily consumed by
an external program?

Thanks,
Sean