[dpdk-dev] Pcap question

Yep, It did resolved the issue. I also think it should be handled somehow by default, because Ubuntu is not an esoteric distro. Why not patching it as well? Anyway great work! On Mon, Mar 3, 2014 at 11:37 PM, Olivier MATZ wrote: > On 03/03/2014 10:31 PM, Olivier MATZ wrote: > >>LIBPCAP_LD

[dpdk-dev] Pcap question

Hi Olivier, make V=1 output (last lines): == Build lib/librte_meter == Build lib/librte_sched == Build lib/librte_kni == Build app make S=app -f /home/cigol/libs/dpdk-1.6.0r1-patch/app/Makefile -C /home/cigol/libs/dpdk-1.6.0r1-patch/build/build/app all == Build app/test gcc -m64 -pthread -march=

[dpdk-dev] Pcap question

On 03/03/2014 10:31 PM, Olivier MATZ wrote: >LIBPCAP_LDFLAGS ?= $(patsubst -Wl$(comma),%,$(shell pcap-config --libs)) I forgot a %: LIBPCAP_LDFLAGS ?= $(patsubst -Wl$(comma)%,%,$(shell pcap-config --libs))

[dpdk-dev] Pcap question

Hi Meir, On 03/03/2014 10:09 PM, Meir Tseitlin wrote: > -Wl,-lrte_pmd_pcap -Wl,-L/usr/local/lib -Wl,-Wl,-rpath,/usr/local/lib > -Wl,-lpcap The problem is related to the lines above. They are generated in rte.app.mk: ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) LDLIBS += -lrte_pmd_pcap LIBPCAP

[dpdk-dev] Pcap question

Hi Meir, On 03/03/2014 08:31 PM, Meir Tseitlin wrote: > The patch did solved compilation errors (Thanks!), but now I am again > experiencing linkage error with executables I had in previous versions > as well: > >LD dump_cfg > /usr/bin/ld: unrecognized option '-Wl' > /usr/bin/ld: use the --hel

[dpdk-dev] Pcap question

Hi Olivier, The patch did solved compilation errors (Thanks!), but now I am again experiencing linkage error with executables I had in previous versions as well: LD dump_cfg /usr/bin/ld: unrecognized option '-Wl' /usr/bin/ld: use the --help option for usage information collect2: error: ld retur

[dpdk-dev] Physical core vs. hyper threaded core

Thanks Jane. Statically allocated are resources like load buffer, store buffer, reorder buffer and small page ITB. In addition, there are other resources that are replicated, competitively shared. Below are couple of links that you will find useful. http://software.intel.com/en-us/articles

[dpdk-dev] Physical core vs. hyper threaded core

Thanks Muthurajan. " because there are some resources statically partitioned" What are these resources and in general what types of operations from the software will be impacted? Like memory access, IO access etc.? Under what condition would sharing sibling lcores for 2 DPDK threads would be r

[dpdk-dev] [PATCH 09/11] device-args: replace use-device eal option by pci-whitelist and vdev

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz > Sent: Friday, February 28, 2014 5:26 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 09/11] device-args: replace use-device eal > option by pci-whitelist and vdev > > This commit splits the

[dpdk-dev] fedora 19 / 20

Does DPDK support fedora 19 and/or fedora 20. Has anyone tested with these distributions. Thanks.

[dpdk-dev] Building on FreeBSD

All, I see in both the announcements and release notes support for building and running on FreeBSD. However, there are no instructions, nor does the "Intel DPDK for FreeBSD* Getting Started Guide" exist. Is this forthcoming? I've at least figured out to use 'gmake' instead of make. But is th

[dpdk-dev] are these bypass api supported on Intel Bandon Beach card : of device id : 8086:155d

can anyone please let me know about this... thanks, Sharath On Sat, Mar 1, 2014 at 5:06 PM, Sharath wrote: > Hi > > we are using DPDK 1.5.1_7. > our PCI slot has Intel Bandon Beach NIC. > > > Can anyone please let me know, whether the below api's are supported in > the NIC type [8086:155d] > >

[dpdk-dev] are these bypass api supported on Intel Bandon Beach card : of device id : 8086:155d

Hi, Yes Bandon Beach should be supported starting from 1.5.1. Though to enable it you need to set CONFIG_RTE_NIC_BYPASS=y in your config file. Konstantin -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Sharath Sent: Monday, March 03, 2014 6:13 AM To: dev at dpdk.

[dpdk-dev] Physical core vs. hyper threaded core

In your scenario, NO interference with DPDK. Perfect. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jayakumar, Muthurajan Sent: Sunday, March 02, 2014 6:23 PM To: Jane Shen; dev at dpdk.org Subject: Re: [dpdk-dev] Physical core vs. hyper threaded core Thanks Jane

[dpdk-dev] Physical core vs. hyper threaded core

Thanks Jane. Great. So interference with DPDK. Perfect. The reason for using physical core is, you get more resources compared to using in hyperthreaded mode this is because there are some resources statically partitioned and so when one disables hyperthreaded mode and use physical core, then

[dpdk-dev] Physical core vs. hyper threaded core

Thanks Muthurajan. We were testing with core 0-7 to DPDK and 8-15 to Linux SIP processes. The core numbers are based on the Linux /etc/cpuinfo. These processes don't have direct coupling with DPDK. They may share some memory with the DPDK via IPC. What was the reason that it is recommended to u

[dpdk-dev] Physical core vs. hyper threaded core

Jane, Great. You are correct. Have tried enabling hyperthreading and it works. For example, if we want to have the functionality partitioning such that Rx + Packet Processing + Tx = all of these three functions can be done in 2 cores - By positioning Rx in one lcore and by positioning Packet

[dpdk-dev] Physical core vs. hyper threaded core

Hi, I understand that DPDK should use the physical core. But here is what we tested: - Enable HT - Assign 8 cores of the CPU (an 8-core Sandybridge CPU) to DPDK. Surprisingly enough, we noticed that the remaining 8 cores (b/c there are total of 16 cores after HT) can still ha