Differences

This shows you the differences between two versions of the page.

--- projectsroutingproposal:api [2016/01/16 12:50] – AlexanderChernikov
+++ projectsroutingproposal:api [2016/01/17 08:25] (current) – AlexanderChernikov
@@ Line 3: / Line 3: @@
 ===== LLTABLE =====
 There are 2 main functions in lltable used to lookup lladdr data by external callers:
-//int arpresolve(ifnet *ifp, int is_gw, mbuf *m, sockaddr *dst, u_char *desten, uint32_t *pflags)// and the corresponding
-//int nd6_resolve(ifnet *ifp, int is_gw, mbuf *m, sockaddr *dst, u_char *desten, uint32_t *pflags)//
+<code>
+int arpresolve(ifnet *ifp, int is_gw, mbuf *m, sockaddr *dst, u_char *desten, uint32_t *pflags)
+</code>
+and the corresponding
+<code>
+int nd6_resolve(ifnet *ifp, int is_gw, mbuf *m, sockaddr *dst, u_char *desten, uint32_t *pflags)
+</code>
 ==== API Problems ====
@@ Line 17: / Line 24: @@
 ==== New API ====
 Given that, set of 2 new lookup functions is proposed:
-//int lle4_lookup(ifnet *ifp, mbuf *m, struct in_addr dst, u_char *desten, uint32_t *pflags)// and the corresponding
-//int lle6_lookup(ifnet *ifp, mbuf *m, struct in6_addr *dst, u_char *desten, uint32_t *pflags)//
+<code>
+int in_resolve_lla(ifnet *ifp, mbuf *m, struct in_addr dst, u_char *desten, uint32_t *pflags)
+int in6_resolve_lla(ifnet *ifp, mbuf *m, struct in6_addr *dst, u_char *desten, uint32_t *pflags)
+</code>
-More details in DXXXX.
+More details in [[https://reviews.freebsd.org/D4962|D4962]].
 ===== Routing =====
@@ Line 34: / Line 43: @@
 ==== API problems ====
 === Locking rtentry ===
-Rte is locked and refcounted to ensure that the caller can safely dereference rtentry fields. The important fact here is that **refcounting rtentry does not protect you from rt_ifp ifnet being destroyed after lookup**. The only refcount that is hold by rtentry is rt_ifa (which, in turn, is just a structure not refcounting anything itself). So, **refcounting rtentry just gives you stable storage, nothing more**. Theoretically, rtentry could be copied to stack structure, but it practice it's not feasible (sizeof(struct rtentry) > 200 bytes on amd64, with prefix/gw allocated separately, netmask pointer from radix, etc..).
+Rte is locked and refcounted to ensure that the caller can safely dereference rtentry fields. The important fact here is that **refcounting rtentry does not protect you from rt_ifp ifnet being destroyed after lookup**.
+The only refcount that is hold by rtentry is rt_ifa (which, in turn, is just a structure not refcounting anything itself). So, **refcounting rtentry just gives you stable storage, nothing more**. Theoretically, rtentry could be copied to stack structure, but in practice it's not feasible (sizeof(struct rtentry) > 200 bytes on amd64, with prefix/gw allocated separately, netmask pointer from radix, etc..).
 === Caller complexity ===
 Instead of getting pre-computed result consumer has to alter the results itself: if RTF_GATEWAY is set then.., check which MTU is less: rt_mtu or ifp->ifp_mtu or rt_ifa->ifa_ifp->ifp_mtu or IN6_LINKMTU(), etc.
@@ Line 47: / Line 58: @@
   * Use compact on-stack structures
   * Provide different functions for different tasks varying in terms of provided information and speed
+  * Have per-AF functions and use addresses instead of sockaddr
   * Be multipath-ready from day 1.
   * Hide all of the internals avoiding passing rtentries to any data/control plane functions outside routing code.
-=== Functions ===
+=== Data path functions ===
-== Data path ==
 This set of functions return minimal amount of data needed to forward a packet (or verify some basic data), e.g. next-hop data.
 Nexthop consists of interface, mtu, flags, data to prepend or next-hop address. Right now next-hop size is 64 bytes (leaving about 40 bytes for pre-calculated prepend data like ethernet header).
@@ Line 59: / Line 70: @@
   - Different lookup algorithms _are_ required: patricia is not so well suited for long IPv6 keys. Additionally, cases like 'single interface-with-default-route' and 'I have IPv4 full-view' also deserves different algorithms to achieve optimal performance. So, having next-hops is a necessary pre-requisite for making infrastructure for modular lookup algorithms (see ipfw(4) modular tables lookup infrastructure where similar ideas were implemented).
-Actual functions with appropriate data structures:
+Source: [[https://svnweb.freebsd.org/base/head/sys/netinet/in_fib.c?view=markup|ip_fib.c]] [[https://svnweb.freebsd.org/base/head/sys/netinet/in_fib.h?view=markup|ip_fib.h]] [[https://svnweb.freebsd.org/base/head/sys/netinet6/in6_fib.c?view=markup|in6_fib.c]] [[https://svnweb.freebsd.org/base/head/sys/netinet6/in6_fib.h?view=markup|in6_fib.h]]
+Actual functions description:
+== fibX_lookup_nh_basic() ==
+The simplest form of lookup, no references are provided.
 <code>
@@ Line 107: / Line 122: @@
 </code>
-**The simplest form of lookup, no references are provided.**
+== fibX_lookup_nh_ext() ==
+More advanced one: IPv4 source address is returned, some pointers can be referenced if required. Right now internal referencing/dereferencing is a no-op (which is exactly like current rtalloc/rte implementation).
 <code>
@@ Line 133: / Line 149: @@
         uint64_t        spare2[2];
 };
+void fib4_free_nh_ext(uint32_t fibnum, struct nhop4_extended *pnh4)
 /*
@@ Line 155: / Line 172: @@
         uint64_t        spare2[2];
 };
+void fib6_free_nh_ext(uint32_t fibnum, struct nhop6_extended *pnh6)
 </code>
-**More advanced one: IPv4 source address is returned, some pointers can be referenced if required. Right now internal referencing/dereferencing is a no-op (which is exactly like current rtalloc/rte implementation).**
+== fibX_lookup_prepend() ==
+Actual functions used for forwarding. Passing //struct route// permits function to automatically program //ro_len//, //ro_flags// and //ro_prepend// fields so route pre-calculated data could be transparently passed to the output function.
 <code>
+/*
+ * Performs lookup in IPv4 table fib @fibnum.
+ * Assumes @ro->ro_rt points to 'struct nhop_prepend' storage.
+ * In case of successful lookup ro->ro_rt is filled with
+ * appropriate interface info and full L2 header to prepend or
+ * nhop address. If route does not contain gateway, or gateway is unreachable,
+ * NHF_L2_INCOMPLETE flag and gateway address is stored into nh->d.gw4
+ * If @hh is not NULL, additional nexthop data is stored there.
+ *
+ * Returns 0 on success.
+ */
+int fib4_lookup_prepend(uint32_t fibnum, struct in_addr dst, uint32_t flags, uint32_t flowid, struct route *ro, struct nhop4_helper *hh);
+/* Non-recursive nexthop */
+struct nhop_prepend {
+        uint16_t        nh_flags;       /* NH flags */
+        uint8_t         nh_count;       /* Number of nexthops or data length */
+        uint8_t         spare[3];
+        uint16_t        nh_mtu;         /* given nhop MTU */
+        struct ifnet    *nh_lifp;       /* Logical transmit interface */
+        struct ifnet    *nh_aifp;       /* Interface address  */
+        union {
+                char    nh_data[MAX_PREPEND_LEN];       /* data to prepend */
+                struct in_addr  nh4_addr;/* IPv4 gw address */
+                struct in6_addr nh6_addr;/* IPv4 gw address */
+        };
+};
+void fib4_free_prepend(struct nhop_prepend *pnh);
 </code>
-**Actual functions used for forwarding**
+=== Control plane functions ===
+Some consumers want to check if particular prefix exists, or check actual rte flags, which cannot be achieved using fibX functions. Luckily, all(most) there consumers are control-plane ones (arp/nd code).
+== rib_lookup() ==
+The goal is to provide real per-rte information and, if possible, avoid direct rte access. This is accomplished by using //struct rt_addrinfo// used as interaction mechanism between routing socket and routing table functions. The tricky part here is that //rt_addrinfo// itself does not have storage for prefx,mask and gateway (the latter could be of any size). So, the decision is the following: caller allocates (either on-stack or memory) sockaddrs of appropriate size for the fields it want to retrieve, sets //sa.sa_len// field to the size of allocated buffer and sets //info.rti_info[RTAX_XXX]// pointer to that sockaddr. Function then tries to fill all non-zero sockaddr on successful lookup.
+<code>
+/*
+ * Lookups up route entry for @dst in RIB database for fib @fibnum.
+ * Exports entry data to @info using rt_exportinfo().
+ *
+ * if @flags contains NHR_REF, refcouting is performed on rt_ifp.
+ *   All references can be released later by calling rib_free_info()
+ *
+ * Returns 0 on success.
+ * Returns ENOENT for lookup failure, ENOMEM for export failure.
+ */
+int rib_lookup_info(uint32_t fibnum, const struct sockaddr *dst, uint32_t flags, uint32_t flowid, struct rt_addrinfo *info)
+void rib_free_info(struct rt_addrinfo *info)
+</code>