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

110 lines
2.9 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 10:24:24 +00:00
*/
#ifndef __L3FWD_EM_H__
#define __L3FWD_EM_H__
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 09:27:25 +00:00
static __rte_always_inline void
ethdev: increase port id range Extend port_id definition from uint8_t to uint16_t in lib and drivers data structures, specifically rte_eth_dev_data. Modify the APIs, drivers and app using port_id at the same time. Fix some checkpatch issues from the original code and remove some unnecessary cast operations. release_17_11 and deprecation docs have been updated in this patch. Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
2017-09-29 07:17:24 +00:00
l3fwd_em_simple_forward(struct rte_mbuf *m, uint16_t portid,
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 10:33:07 +00:00
struct lcore_conf *qconf)
{
struct ether_hdr *eth_hdr;
struct ipv4_hdr *ipv4_hdr;
ethdev: increase port id range Extend port_id definition from uint8_t to uint16_t in lib and drivers data structures, specifically rte_eth_dev_data. Modify the APIs, drivers and app using port_id at the same time. Fix some checkpatch issues from the original code and remove some unnecessary cast operations. release_17_11 and deprecation docs have been updated in this patch. Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
2017-09-29 07:17:24 +00:00
uint16_t dst_port;
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 00:47:46 +00:00
uint32_t tcp_or_udp;
uint32_t l3_ptypes;
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 10:33:07 +00:00
eth_hdr = rte_pktmbuf_mtod(m, struct ether_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 00:47:46 +00:00
tcp_or_udp = m->packet_type & (RTE_PTYPE_L4_TCP | RTE_PTYPE_L4_UDP);
l3_ptypes = m->packet_type & RTE_PTYPE_L3_MASK;
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 10:33:07 +00: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 00:47:46 +00:00
if (tcp_or_udp && (l3_ptypes == RTE_PTYPE_L3_IPV4)) {
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 10:33:07 +00:00
/* Handle IPv4 headers.*/
ipv4_hdr = rte_pktmbuf_mtod_offset(m, struct ipv4_hdr *,
sizeof(struct ether_hdr));
#ifdef DO_RFC_1812_CHECKS
/* Check to make sure the packet is valid (RFC1812) */
if (is_valid_ipv4_pkt(ipv4_hdr, m->pkt_len) < 0) {
rte_pktmbuf_free(m);
return;
}
#endif
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 00:47:46 +00:00
dst_port = em_get_ipv4_dst_port(ipv4_hdr, portid,
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 10:33:07 +00:00
qconf->ipv4_lookup_struct);
if (dst_port >= RTE_MAX_ETHPORTS ||
(enabled_port_mask & 1 << dst_port) == 0)
dst_port = portid;
#ifdef DO_RFC_1812_CHECKS
/* Update time to live and header checksum */
--(ipv4_hdr->time_to_live);
++(ipv4_hdr->hdr_checksum);
#endif
/* dst addr */
*(uint64_t *)&eth_hdr->d_addr = dest_eth_addr[dst_port];
/* src addr */
ether_addr_copy(&ports_eth_addr[dst_port], &eth_hdr->s_addr);
send_single_packet(qconf, m, dst_port);
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 00:47:46 +00:00
} else if (tcp_or_udp && (l3_ptypes == RTE_PTYPE_L3_IPV6)) {
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 10:33:07 +00:00
/* Handle IPv6 headers.*/
struct ipv6_hdr *ipv6_hdr;
ipv6_hdr = rte_pktmbuf_mtod_offset(m, struct ipv6_hdr *,
sizeof(struct ether_hdr));
dst_port = em_get_ipv6_dst_port(ipv6_hdr, portid,
qconf->ipv6_lookup_struct);
if (dst_port >= RTE_MAX_ETHPORTS ||
(enabled_port_mask & 1 << dst_port) == 0)
dst_port = portid;
/* dst addr */
*(uint64_t *)&eth_hdr->d_addr = dest_eth_addr[dst_port];
/* src addr */
ether_addr_copy(&ports_eth_addr[dst_port], &eth_hdr->s_addr);
send_single_packet(qconf, m, dst_port);
} else {
/* Free the mbuf that contains non-IPV4/IPV6 packet */
rte_pktmbuf_free(m);
}
}
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 10:24:24 +00:00
/*
* Buffer non-optimized handling of packets, invoked
* from main_loop.
*/
static inline void
l3fwd_em_no_opt_send_packets(int nb_rx, struct rte_mbuf **pkts_burst,
ethdev: increase port id range Extend port_id definition from uint8_t to uint16_t in lib and drivers data structures, specifically rte_eth_dev_data. Modify the APIs, drivers and app using port_id at the same time. Fix some checkpatch issues from the original code and remove some unnecessary cast operations. release_17_11 and deprecation docs have been updated in this patch. Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
2017-09-29 07:17:24 +00: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 10:24:24 +00:00
{
int32_t j;
/* Prefetch first packets */
for (j = 0; j < PREFETCH_OFFSET && j < nb_rx; j++)
rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[j], void *));
/*
* Prefetch and forward already prefetched
* packets.
*/
for (j = 0; j < (nb_rx - PREFETCH_OFFSET); j++) {
rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[
j + PREFETCH_OFFSET], void *));
l3fwd_em_simple_forward(pkts_burst[j], portid, qconf);
}
/* Forward remaining prefetched packets */
for (; j < nb_rx; j++)
l3fwd_em_simple_forward(pkts_burst[j], portid, qconf);
}
#endif /* __L3FWD_EM_H__ */
Reference in New Issue Copy Permalink