rte_table_lpm_ipv6.h(3)

💖 rte_table_lpm_ipv6.h — a.k.a. the rte_table_lpm_ipv6.h(3) glow-up

okay bestie, sit down, grab a strawberry matcha, because we're reading a Library Functions Manual page together and honestly? it's giving routing table royalty 👑

---

✨ NAME ✨

rte_table_lpm_ipv6.h — yes that's literally it, the whole name, she's mysterious like that 💅

---

🌸 SYNOPSIS 🌸

first things first, pull in your little friends:

#include <stdint.h>
#include <rte_common.h>
#include <rte_ip6.h>
#include 'rte_table.h'

bestie the single quotes around 'rte_table.h' are exactly how it's written here, do not come for me, I am simply the messenger 🫶

🎀 Data Structures

• struct rte_table_lpm_ipv6_params
• struct rte_table_lpm_ipv6_key

🦋 Variables

• struct rte_table_ops rte_table_lpm_ipv6_ops

---

🌈 DETAILED DESCRIPTION 🌈

RTE Table LPM for IPv6

so this table uses the Longest Prefix Match (LPM) algorithm to uniquely associate data to lookup keys. no cap. it's the main character of prefix matching.

Use-case: IP routing table. Routes that are added to the table associate a next hop to an IP prefix. The IP prefix is specified as IP address and depth, and it covers for a multitude of lookup keys (i.e. destination IP addresses) that all share the same data (i.e. next hop). The next hop information typically contains the output interface ID, the IP address of the next hop station (which is part of the same IP network the output interface is connected to) and other flags and counters.

okay now here's the plot twist 😭 — the LPM primitive only allows associating an 8-bit number (next hop ID) to an IP prefix, while a routing table can potentially contain thousands of routes or even more. so like... you're putting a whole wardrobe into one tiny clutch. This means that the same next hop ID (and next hop information) has to be shared by multiple routes, which makes sense, as multiple remote networks could be reached through the same next hop. Therefore, when a route is added or updated, the LPM table has to check whether the same next hop is already in use before using a new next hop ID for this route.

the comparison between different next hops is done for the first entry_unique_size bytes of the next hop information (that's a configurable parameter, bestie), which have to uniquely identify the next hop. therefore the user has to carefully manage the format of the LPM table entry (i.e. the next hop information) so that any next hop data that changes value during run-time (e.g. counters) is placed outside of this area.

🚨 lowkey the most important homework here: counters and other runtime-changing data cannot live inside the entry_unique_size region. if they do, your "unique" identification isn't unique anymore and the table's whole vibe check fails. that's the documented caveat, fr fr.

Definition in file rte_table_lpm_ipv6.h.

---

🔥 VARIABLE DOCUMENTATION 🔥

struct rte_table_ops rte_table_lpm_ipv6_ops [extern]

LPM table operations — that's the ops struct, the icon, the blueprint, the whole moment 👑

---

👑 AUTHOR 👑

Generated automatically by Doxygen for DPDK from the source code.

(yes she was born from a doc generator, no she does not need your attitude about it, she's still iconic ✨)

---

and that's the page, bestie!! this loveliness ships with DPDK, Version 25.11.3, and it's rte_table_lpm_ipv6.h(3) — catch you on the next manpage 💖🦋🎀 periodt.