Differences

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

--- projectsroutingproposal:api [2016/01/16 13:09] – AlexanderChernikov
+++ projectsroutingproposal:api [2016/01/17 08:25] (current) – AlexanderChernikov
@@ Line 26: / Line 26: @@
 <code>
-int lle4_lookup(ifnet *ifp, mbuf *m, struct in_addr dst, u_char *desten, uint32_t *pflags)
+int in_resolve_lla(ifnet *ifp, mbuf *m, struct in_addr dst, u_char *desten, uint32_t *pflags)
-int lle6_lookup(ifnet *ifp, mbuf *m, struct in6_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 58: / 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.
@@ Line 69: / 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.
@@ Line 174: / Line 177: @@
 == fibX_lookup_prepend() ==
-Actual functions used for forwarding
+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>
+=== 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>