[dpdk-dev] [PATCH v2] lpm: fix build error on g++ with -O0 option

prevents DPDK programs from building. This patch replaces "sizeof(uint64_t)" with a constant literal "8" to work around the issue. The issue occurs on gcc/g++ versions from 4.8 to 5. Signed-off-by: Sangjin Han --- v2: * Added a comment * Updated the commit message: both gcc

[dpdk-dev] [PATCH] lpm: fix build error on g++ with -O0 option

this error prevents C++ programs from building. This patch replaces "sizeof(uint64_t)" with a constant literal "8" to work around the issue. Tested with g++ 5.4.1. Signed-off-by: Sangjin Han --- lib/librte_lpm/rte_lpm_sse.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(

[dpdk-dev] QoS Question

Hi, According to "21.2.4.6.6.2", it seems that the implementation is supposed to achieve max-min fairness. In your example, the effective cap of single active pipe should be 1Mbps, given the total demand of other 1999 pipes is less than 999Mbps. Sangjin On Mon, Apr 20, 2015 at 9:40 AM Greg Smith

[dpdk-dev] Is it possible to get symmetric hash from RSS for a given flow

Hi, This is exactly what you want: http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf Sangjin On Thu, Feb 27, 2014 at 4:22 PM, Daniel Kan wrote: > Hi, > It appears that the hash computed from RSS is unidirectional. Hence, for a > 5-tuple flow, packet in one direction can be routed to a que

[dpdk-dev] [PATCH] timer: add lfence before TSC read

Why LFENCE, rather than CPUID? I guess LFENCE does not prevent out-of-order execution for non-load instructions across it. This link has detailed information on RDTSC, RDTSCP, and CPUID: http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ia-32-ia-64-benchmark-code-execution-p

[dpdk-dev] "No probed ethernet devices" caused by inaccurate msec_delay()

Hi, >> It would be nice if I can bypass set_tsc_freq_from_cpuinfo() in >> set_tsc_freq(). > > I think it would not solve the problem because your clock is varying and the > TSC calibration must be updated accordingly with different values by core. Reasonably new Intel CPUs (including Nehalem) has

[dpdk-dev] "No probed ethernet devices" caused by inaccurate msec_delay()

Hi, I encountered this error message when I tried to use the testpmd application. Cause: No probed ethernet devices - check that CONFIG_RTE_LIBRTE_IGB_PMD=y and that CONFIG_RTE_LIBRTE_EM_PMD=y and that CONFIG_RTE_LIBRTE_IXGBE_PMD=y in your configuration file which is caused by rte_eth_dev_count(