rte_table_lpm.h(3)

💖 rte_table_lpm.h — bestie's guide to the LPM table 💖

okay so this is a page from the DPDK library manual, section 3 (library functions), and it's literally all about the RTE Table LPM for IPv4. no cap, it's a banger. let's get into it 🦋

---

✨ SYNOPSIS ✨

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

🎀 Data Structures

• struct rte_table_lpm_params
• struct rte_table_lpm_key

🎀 Variables

• struct rte_table_ops rte_table_lpm_ops

---

🌸 Detailed Description 🌸

RTE Table LPM for IPv4 — she's the moment, she's the blueprint 💅

This table uses the Longest Prefix Match (LPM) algorithm to uniquely associate data to lookup keys. yes bestie, uniquely. that's the whole point.

Use-case: IP routing table. fr fr, this is what she was born to do. 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 a multitude of lookup keys (i.e. destination IP addresses) that all share the same data (i.e. next hop). And what's inside that next hop info? Typically 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), plus other flags and counters. the whole vibe 🫶

The LPM primitive only allows associating an 8-bit number (next hop ID) to an IP prefix — and a routing table can potentially contain thousands of routes or even more. so yeah, one lil 8-bit ID cannot possibly hold a whole next hop per route. this means the same next hop ID (and next hop information) has to be shared by multiple routes, which makes total 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. it's giving responsible king energy 👑

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, btw), 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.

⚠️ bestie, hear me: if you let a counter live inside those first "entry_unique_size" bytes, the uniqueness comparison gets wrecked. keep the changing stuff out of that zone. periodt.

Definition in file rte_table_lpm.h.

---

🧚 Variable Documentation 🧚

struct rte_table_ops rte_table_lpm_ops [extern]

LPM table operations 🌈

---

👑 Author 👑

Generated automatically by Doxygen for DPDK from the source code.

---

byeee besties 🫶 this one's from DPDK, version 25.11.3, pages of rte_table_lpm.h(3), and she was auto-generated for the DPDK source code. slay, stay unique-length, and don't forget to vibe check your next hop IDs 💜✨