]>
Commit | Line | Data |
---|---|---|
9f95a23c TL |
1 | /* SPDX-License-Identifier: BSD-3-Clause |
2 | * Copyright(c) 2010-2014 Intel Corporation | |
7c673cae FG |
3 | */ |
4 | ||
5 | #ifndef __INCLUDE_RTE_TABLE_LPM_H__ | |
6 | #define __INCLUDE_RTE_TABLE_LPM_H__ | |
7 | ||
8 | #ifdef __cplusplus | |
9 | extern "C" { | |
10 | #endif | |
11 | ||
12 | /** | |
13 | * @file | |
14 | * RTE Table LPM for IPv4 | |
15 | * | |
16 | * This table uses the Longest Prefix Match (LPM) algorithm to uniquely | |
17 | * associate data to lookup keys. | |
18 | * | |
19 | * Use-case: IP routing table. Routes that are added to the table associate a | |
20 | * next hop to an IP prefix. The IP prefix is specified as IP address and depth | |
21 | * and cover for a multitude of lookup keys (i.e. destination IP addresses) | |
22 | * that all share the same data (i.e. next hop). The next hop information | |
23 | * typically contains the output interface ID, the IP address of the next hop | |
24 | * station (which is part of the same IP network the output interface is | |
25 | * connected to) and other flags and counters. | |
26 | * | |
27 | * The LPM primitive only allows associating an 8-bit number (next hop ID) to | |
28 | * an IP prefix, while a routing table can potentially contain thousands of | |
29 | * routes or even more. This means that the same next hop ID (and next hop | |
30 | * information) has to be shared by multiple routes, which makes sense, as | |
31 | * multiple remote networks could be reached through the same next hop. | |
32 | * Therefore, when a route is added or updated, the LPM table has to check | |
33 | * whether the same next hop is already in use before using a new next hop ID | |
34 | * for this route. | |
35 | * | |
36 | * The comparison between different next hops is done for the first | |
37 | * “entry_unique_size” bytes of the next hop information (configurable | |
38 | * parameter), which have to uniquely identify the next hop, therefore the user | |
39 | * has to carefully manage the format of the LPM table entry (i.e. the next | |
40 | * hop information) so that any next hop data that changes value during | |
41 | * run-time (e.g. counters) is placed outside of this area. | |
42 | * | |
43 | ***/ | |
44 | ||
45 | #include <stdint.h> | |
46 | ||
47 | #include "rte_table.h" | |
48 | ||
49 | /** LPM table parameters */ | |
50 | struct rte_table_lpm_params { | |
51 | /** Table name */ | |
52 | const char *name; | |
53 | ||
54 | /** Maximum number of LPM rules (i.e. IP routes) */ | |
55 | uint32_t n_rules; | |
56 | ||
57 | /**< Number of tbl8s to allocate. */ | |
58 | uint32_t number_tbl8s; | |
59 | ||
60 | /**< This field is currently unused. */ | |
61 | int flags; | |
62 | ||
63 | /** Number of bytes at the start of the table entry that uniquely | |
64 | identify the entry. Cannot be bigger than table entry size. */ | |
65 | uint32_t entry_unique_size; | |
66 | ||
67 | /** Byte offset within input packet meta-data where lookup key (i.e. | |
68 | the destination IP address) is located. */ | |
69 | uint32_t offset; | |
70 | }; | |
71 | ||
72 | /** LPM table rule (i.e. route), specified as IP prefix. While the key used by | |
73 | the lookup operation is the destination IP address (read from the input packet | |
74 | meta-data), the entry add and entry delete operations work with LPM rules, with | |
75 | each rule covering for a multitude of lookup keys (destination IP addresses) | |
76 | that share the same data (next hop). */ | |
77 | struct rte_table_lpm_key { | |
78 | /** IP address */ | |
79 | uint32_t ip; | |
80 | ||
81 | /** IP address depth. The most significant "depth" bits of the IP | |
82 | address specify the network part of the IP address, while the rest of | |
83 | the bits specify the host part of the address and are ignored for the | |
84 | purpose of route specification. */ | |
85 | uint8_t depth; | |
86 | }; | |
87 | ||
88 | /** LPM table operations */ | |
89 | extern struct rte_table_ops rte_table_lpm_ops; | |
90 | ||
91 | #ifdef __cplusplus | |
92 | } | |
93 | #endif | |
94 | ||
95 | #endif |