d/numam-dpdk
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
numam-dpdk/examples/l3fwd/l3fwd_em_sequential.h

125 lines
3.0 KiB
C
Raw Normal View History

examples: use SPDX tag for Intel copyright files Replace the BSD license header with the SPDX tag for files with only an Intel copyright on them. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
2017-12-19 15:49:02 +00:00
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2010-2016 Intel Corporation
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-25 11:24:24 +01:00
*/
examples/l3fwd: rename file for sequential hash lookup The l3fwd_em_sse.h is enabled by NO_HASH_LOOKUP_MULTI. Renaming it because it's only for sequential hash lookup, and doesn't include any x86 SSE instructions. Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
2017-07-04 18:23:59 +08:00
#ifndef __L3FWD_EM_SEQUENTIAL_H__
#define __L3FWD_EM_SEQUENTIAL_H__
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-25 11:24:24 +01:00
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: 94c54b4158d5 ("examples/l3fwd: rework exact-match") Fixes: dc81ebbacaeb ("lpm: extend IPv4 next hop field") Fixes: 64d3955de1de ("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-18 14:31:46 +01:00
/**
* @file
* This is an optional implementation of packet classification in Exact-Match
* path using sequential packet classification method.
* While hash lookup multi seems to provide better performance, it's disabled
* by default and can be enabled with NO_HASH_LOOKUP_MULTI global define in
* compilation time.
*/
examples/l3fwd: add NEON implementation Use ARM NEON intrinsics to accelerate l3 fowarding. Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
2017-07-04 18:24:03 +08:00
#if defined RTE_ARCH_X86
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:33:07 +01:00
#include "l3fwd_sse.h"
build: remove deprecated cpuflag macros Replace use of RTE_MACHINE_CPUFLAG macros with regular compiler macros, which are more complete than those provided by DPDK, and as such it allows new instruction sets to be leveraged without having to do extra work to set them up in DPDK. Signed-off-by: Sean Morrissey <sean.morrissey@intel.com> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com> Acked-by: David Marchand <david.marchand@redhat.com>
2020-09-24 08:18:29 +00:00
#elif defined __ARM_NEON
examples/l3fwd: add NEON implementation Use ARM NEON intrinsics to accelerate l3 fowarding. Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
2017-07-04 18:24:03 +08:00
#include "l3fwd_neon.h"
#endif
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-25 11:24:24 +01:00
eal: introduce macro for always inline Different drivers use internal macros like force_inline for compiler always inline feature. Standardizing it through __rte_always_inline macro. Verified the change by comparing the output binary file. No difference found in the output binary file with this change. Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
2017-05-13 14:57:25 +05:30
static __rte_always_inline uint16_t
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:33:07 +01:00
em_get_dst_port(const struct lcore_conf *qconf, struct rte_mbuf *pkt,
examples: fix port id type Fixes: f8244c6399d9 ("ethdev: increase port id range") Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com>
2017-10-13 21:17:00 +08:00
uint16_t portid)
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-25 11:24:24 +01:00
{
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:33:07 +01:00
uint8_t next_hop;
net: add rte prefix to IP structure Add 'rte_' prefix to structures: - rename struct ipv4_hdr as struct rte_ipv4_hdr. - rename struct ipv6_hdr as struct rte_ipv6_hdr. Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
2019-05-21 18:13:10 +02:00
struct rte_ipv4_hdr *ipv4_hdr;
struct rte_ipv6_hdr *ipv6_hdr;
examples/l3fwd: fix using packet type blindly As a example to use ptype info, l3fwd needs firstly to use rte_eth_dev_get_supported_ptypes() API to check if device and/or its PMD driver will parse and fill the needed packet type; if not, use the newly added option, --parse-ptype, to analyze it in the callback softly. As the mode of EXACT_MATCH uses the 5 tuples to caculate hash, so we narrow down its scope to: a. ip packets with no extensions, and b. L4 payload should be either tcp or udp. Note: this patch does not completely solve the issue, "cannot run l3fwd on virtio or other devices", because hw_ip_checksum may be not supported by the devices. Currently we can: a. remove this requirements, or b. wait for virtio front end (pmd) to support it. Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
2016-03-25 08:47:46 +08:00
uint32_t tcp_or_udp;
uint32_t l3_ptypes;
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-25 11:24:24 +01:00
examples/l3fwd: fix using packet type blindly As a example to use ptype info, l3fwd needs firstly to use rte_eth_dev_get_supported_ptypes() API to check if device and/or its PMD driver will parse and fill the needed packet type; if not, use the newly added option, --parse-ptype, to analyze it in the callback softly. As the mode of EXACT_MATCH uses the 5 tuples to caculate hash, so we narrow down its scope to: a. ip packets with no extensions, and b. L4 payload should be either tcp or udp. Note: this patch does not completely solve the issue, "cannot run l3fwd on virtio or other devices", because hw_ip_checksum may be not supported by the devices. Currently we can: a. remove this requirements, or b. wait for virtio front end (pmd) to support it. Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
2016-03-25 08:47:46 +08:00
tcp_or_udp = pkt->packet_type & (RTE_PTYPE_L4_TCP | RTE_PTYPE_L4_UDP);
l3_ptypes = pkt->packet_type & RTE_PTYPE_L3_MASK;
if (tcp_or_udp && (l3_ptypes == RTE_PTYPE_L3_IPV4)) {
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-25 11:24:24 +01:00
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:33:07 +01:00
/* Handle IPv4 headers.*/
net: add rte prefix to IP structure Add 'rte_' prefix to structures: - rename struct ipv4_hdr as struct rte_ipv4_hdr. - rename struct ipv6_hdr as struct rte_ipv6_hdr. Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
2019-05-21 18:13:10 +02:00
ipv4_hdr = rte_pktmbuf_mtod_offset(pkt, struct rte_ipv4_hdr *,
net: add rte prefix to ether structures Add 'rte_' prefix to structures: - rename struct ether_addr as struct rte_ether_addr. - rename struct ether_hdr as struct rte_ether_hdr. - rename struct vlan_hdr as struct rte_vlan_hdr. - rename struct vxlan_hdr as struct rte_vxlan_hdr. - rename struct vxlan_gpe_hdr as struct rte_vxlan_gpe_hdr. Do not update the command line library to avoid adding a dependency to librte_net. Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
2019-05-21 18:13:03 +02:00
sizeof(struct rte_ether_hdr));
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-25 11:24:24 +01:00
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:33:07 +01:00
next_hop = em_get_ipv4_dst_port(ipv4_hdr, portid,
qconf->ipv4_lookup_struct);
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-25 11:24:24 +01:00
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:33:07 +01:00
if (next_hop >= RTE_MAX_ETHPORTS ||
(enabled_port_mask & 1 << next_hop) == 0)
next_hop = portid;
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-25 11:24:24 +01:00
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:33:07 +01:00
return next_hop;
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-25 11:24:24 +01:00
examples/l3fwd: fix using packet type blindly As a example to use ptype info, l3fwd needs firstly to use rte_eth_dev_get_supported_ptypes() API to check if device and/or its PMD driver will parse and fill the needed packet type; if not, use the newly added option, --parse-ptype, to analyze it in the callback softly. As the mode of EXACT_MATCH uses the 5 tuples to caculate hash, so we narrow down its scope to: a. ip packets with no extensions, and b. L4 payload should be either tcp or udp. Note: this patch does not completely solve the issue, "cannot run l3fwd on virtio or other devices", because hw_ip_checksum may be not supported by the devices. Currently we can: a. remove this requirements, or b. wait for virtio front end (pmd) to support it. Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
2016-03-25 08:47:46 +08:00
} else if (tcp_or_udp && (l3_ptypes == RTE_PTYPE_L3_IPV6)) {
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-25 11:24:24 +01:00
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:33:07 +01:00
/* Handle IPv6 headers.*/
net: add rte prefix to IP structure Add 'rte_' prefix to structures: - rename struct ipv4_hdr as struct rte_ipv4_hdr. - rename struct ipv6_hdr as struct rte_ipv6_hdr. Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
2019-05-21 18:13:10 +02:00
ipv6_hdr = rte_pktmbuf_mtod_offset(pkt, struct rte_ipv6_hdr *,
net: add rte prefix to ether structures Add 'rte_' prefix to structures: - rename struct ether_addr as struct rte_ether_addr. - rename struct ether_hdr as struct rte_ether_hdr. - rename struct vlan_hdr as struct rte_vlan_hdr. - rename struct vxlan_hdr as struct rte_vxlan_hdr. - rename struct vxlan_gpe_hdr as struct rte_vxlan_gpe_hdr. Do not update the command line library to avoid adding a dependency to librte_net. Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
2019-05-21 18:13:03 +02:00
sizeof(struct rte_ether_hdr));
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-25 11:24:24 +01:00
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:33:07 +01:00
next_hop = em_get_ipv6_dst_port(ipv6_hdr, portid,
qconf->ipv6_lookup_struct);
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-25 11:24:24 +01:00
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:33:07 +01:00
if (next_hop >= RTE_MAX_ETHPORTS ||
(enabled_port_mask & 1 << next_hop) == 0)
next_hop = portid;
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-25 11:24:24 +01:00
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:33:07 +01:00
return next_hop;
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-25 11:24:24 +01:00
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:33:07 +01:00
}
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-25 11:24:24 +01:00
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:33:07 +01:00
return portid;
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-25 11:24:24 +01:00
}
/*
* Buffer optimized handling of packets, invoked
* from main_loop.
*/
static inline void
l3fwd_em_send_packets(int nb_rx, struct rte_mbuf **pkts_burst,
examples: fix port id type Fixes: f8244c6399d9 ("ethdev: increase port id range") Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com>
2017-10-13 21:17:00 +08:00
uint16_t portid, struct lcore_conf *qconf)
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-25 11:24:24 +01:00
{
examples/l3fwd: add NEON implementation Use ARM NEON intrinsics to accelerate l3 fowarding. Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
2017-07-04 18:24:03 +08:00
int32_t i, j;
examples/l3fwd: fix size of destination port ids Originally l3fwd used 16-bit value to store dest_port value. To accommodate 24-bit nexthop dest_port was increased to 32-bit, though some further packet processing code remained unchanged and still expects dest_port to be 16-bit. That is not correct and can cause l3fwd invalid behaviour or even process crash/hang on some input packet patterns. For the fix, I choose the simplest approach and restored dest_port as 16-bit value, plus necessary conversions from 32 to 16 bit values after lpm_lookupx4. Fixes: dc81ebbacaeb ("lpm: extend IPv4 next hop field") Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
2016-03-31 14:07:19 +01:00
uint16_t dst_port[MAX_PKT_BURST];
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-25 11:24:24 +01:00
examples/l3fwd: add NEON implementation Use ARM NEON intrinsics to accelerate l3 fowarding. Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
2017-07-04 18:24:03 +08:00
if (nb_rx > 0) {
rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[0],
net: add rte prefix to ether structures Add 'rte_' prefix to structures: - rename struct ether_addr as struct rte_ether_addr. - rename struct ether_hdr as struct rte_ether_hdr. - rename struct vlan_hdr as struct rte_vlan_hdr. - rename struct vxlan_hdr as struct rte_vxlan_hdr. - rename struct vxlan_gpe_hdr as struct rte_vxlan_gpe_hdr. Do not update the command line library to avoid adding a dependency to librte_net. Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
2019-05-21 18:13:03 +02:00
struct rte_ether_hdr *) + 1);
examples/l3fwd: add NEON implementation Use ARM NEON intrinsics to accelerate l3 fowarding. Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
2017-07-04 18:24:03 +08:00
}
for (i = 1, j = 0; j < nb_rx; i++, j++) {
if (i < nb_rx) {
net: add rte prefix to ether structures Add 'rte_' prefix to structures: - rename struct ether_addr as struct rte_ether_addr. - rename struct ether_hdr as struct rte_ether_hdr. - rename struct vlan_hdr as struct rte_vlan_hdr. - rename struct vxlan_hdr as struct rte_vxlan_hdr. - rename struct vxlan_gpe_hdr as struct rte_vxlan_gpe_hdr. Do not update the command line library to avoid adding a dependency to librte_net. Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
2019-05-21 18:13:03 +02:00
rte_prefetch0(rte_pktmbuf_mtod(
pkts_burst[i],
struct rte_ether_hdr *) + 1);
examples/l3fwd: add NEON implementation Use ARM NEON intrinsics to accelerate l3 fowarding. Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
2017-07-04 18:24:03 +08:00
}
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:33:07 +01:00
dst_port[j] = em_get_dst_port(qconf, pkts_burst[j], portid);
examples/l3fwd: add NEON implementation Use ARM NEON intrinsics to accelerate l3 fowarding. Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
2017-07-04 18:24:03 +08:00
}
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-25 11:24:24 +01:00
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:33:07 +01:00
send_packets_multi(qconf, pkts_burst, dst_port, nb_rx);
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-25 11:24:24 +01:00
}
examples/l3fwd: add event em main loop Add em main loop for handling events based on capabilities of the event device. Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com> Acked-by: Jerin Jacob <jerinj@marvell.com>
2020-01-28 11:05:03 +05:30
/*
* Buffer optimized handling of events, invoked
* from main_loop.
*/
static inline void
l3fwd_em_process_events(int nb_rx, struct rte_event **events,
struct lcore_conf *qconf)
{
int32_t i, j;
rte_prefetch0(rte_pktmbuf_mtod(events[0]->mbuf,
struct rte_ether_hdr *) + 1);
for (i = 1, j = 0; j < nb_rx; i++, j++) {
struct rte_mbuf *mbuf = events[j]->mbuf;
if (i < nb_rx) {
rte_prefetch0(rte_pktmbuf_mtod(
events[i]->mbuf,
struct rte_ether_hdr *) + 1);
}
mbuf->port = em_get_dst_port(qconf, mbuf, mbuf->port);
process_packet(mbuf, &mbuf->port);
}
}
examples/l3fwd: rename file for sequential hash lookup The l3fwd_em_sse.h is enabled by NO_HASH_LOOKUP_MULTI. Renaming it because it's only for sequential hash lookup, and doesn't include any x86 SSE instructions. Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
2017-07-04 18:23:59 +08:00
#endif /* __L3FWD_EM_SEQUENTIAL_H__ */
Reference in New Issue Copy Permalink