Commit Graph

5 Commits

Author SHA1 Message Date
Thomas Monjalon
1604ce1e60 examples/l3fwd: remove old SSE4 comments
The flag ENABLE_MULTI_BUFFER_OPTIMIZE has been removed so the
related comments are now useless.

Fixes: 268888b5b0 ("examples/l3fwd: modularize")

Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2016-03-22 20:18:33 +01:00
Tomasz Kulasek
52c97adc1f examples/l3fwd: fix exact match performance
It seems that for the most use cases, previous hash_multi_lookup provides
better performance, and more, sequential lookup can cause significant
performance drop.

This patch sets previously optional hash_multi_lookup method as default.
It also provides some minor optimizations such as queue drain only on used
tx ports.

Fixes: 94c54b4158 ("examples/l3fwd: rework exact-match")
Fixes: dc81ebbaca ("lpm: extend IPv4 next hop field")
Fixes: 64d3955de1 ("examples/l3fwd: fix ARM build")

Reported-by: Qian Xu <qian.q.xu@intel.com>
Signed-off-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
2016-03-21 12:57:02 +01:00
Michal Kobylinski
f1f7261838 lpm: add a new config structure for IPv4
A new rte_lpm_config structure is used so LPM library will allocate
exactly the amount of memory which is necessary to hold application’s
rules.

Signed-off-by: Michal Kobylinski <michalx.kobylinski@intel.com>
Acked-by: David Hunt <david.hunt@intel.com>
2016-03-09 23:05:05 +01:00
Tomasz Kulasek
94c54b4158 examples/l3fwd: rework exact-match
Current implementation of Exact-Match uses different execution path than
for LPM. Unifying them allows to reuse big part of LPM code and sightly
increase performance of Exact-Match.

Main changes:
-------------
* Packet classification stage is separated from the rest of path for both
  LPM and EM.
* Packet processing, modifying and transmit part is the same for LPM and EM
  and mostly based on the current LPM implementation.
* Shared code is moved to the common file "l3fwd_sse.h".
* While sequential packet classification in EM path, seems to be faster
  than using multi hash lookup, used before, it is used by default. Old
  implementation is moved to the file l3fwd_em_hlm_sse.h and can be enabled
  with HASH_LOOKUP_MULTI global define in compilation time.

Signed-off-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
2016-02-29 11:45:00 +01:00
Ravi Kerur
268888b5b0 examples/l3fwd: modularize
The main problem with l3fwd is that it is too monolithic with everything
being in one file, and the various options all controlled by compile time
flags. This means that it's hard to read and understand, and when making
any changes, you need to go to a lot of work to try and ensure you cover
all the code paths, since a compile of the app will not touch large parts
of the l3fwd codebase.

Following changes were done to fix the issues mentioned above

- Split out the various lpm and hash specific functionality into separate
  files, so that l3fwd code has one file for common code e.g. args
  processing, mempool creation, and then individual files for the various
  forwarding approaches.

  Following are new file lists
	  main.c (Common code for args processing, memppol creation, etc)
	  l3fwd_em.c (Hash/Exact match aka 'EM' functionality)
	  l3fwd_em_sse.h (SSE4_1 buffer optimizated 'EM' code)
	  l3fwd_lpm.c (Longest Prefix Match aka 'LPM' functionality)
	  l3fwd_lpm_sse.h (SSE4_1 buffer optimizated 'LPM' code)
	  l3fwd.h (Common include for 'EM' and 'LPM')

- The choosing of the lpm/hash path should be done at runtime, not
  compile time, via a command-line argument. This will ensure that
  both code paths get compiled in a single go

  Following examples show runtime options provided

  Select 'LPM' or 'EM' based on run time selection f.e.
                > l3fwd -c 0x1 -n 1 -- -p 0x1 -E ... (EM)
                > l3fwd -c 0x1 -n 1 -- -p 0x1 -L ... (LPM)
  Options "E" and "L" are mutualy-exclusive.
  If none selected, "L" is default.

Signed-off-by: Ravi Kerur <rkerur@gmail.com>
Signed-off-by: Piotr Azarewicz <piotrx.t.azarewicz@intel.com>
Tested-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Acked-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
2016-02-28 21:56:19 +01:00