aaad3c4fca
One of the goals of the new routing KPI defined in r359823 is to entirely hide`struct rtentry` from the consumers. It will allow to improve routing subsystem internals and deliver more features much faster. This commit is mostly mechanical change to eliminate direct struct rtentry field accesses. The only notable difference is AF_LINK gateway encoding. AF_LINK gw is used in routing stack for operations with interface routes and host loopback routes. In the former case it indicates _some_ non-NULL gateway, as the interface is the same as in rt_ifp in kernel and rtm_ifindex in rtsock reporting. In the latter case the interface index inside gateway was used by the IPv6 datapath to verify address scope for link-local interfaces. Kernel uses struct sockaddr_dl for this type of gateway. This structure allows for specifying rich interface data, such as mac address and interface name. However, this results in relatively large structure size - 52 bytes. Routing stack fils in only 2 fields - sdl_index and sdl_type, which reside in the first 8 bytes of the structure. In the new KPI, struct nhop_object tries to be cache-efficient, hence embodies gateway address inside the structure. In the AF_LINK case it stores stortened version of the structure - struct sockaddr_dl_short, which occupies 16 bytes. After D24340 changes, the data inside AF_LINK gateway will not be used in the kernel at all, leaving rtsock as the only potential concern. The difference in rtsock reporting: (old) got message of size 240 on Thu Apr 16 03:12:13 2020 RTM_ADD: Add Route: len 240, pid: 0, seq 0, errno 0, flags:<UP,DONE,PINNED> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 10.0.0.0 link#5 255.255.255.0 (new) got message of size 200 on Sun Apr 19 09:46:32 2020 RTM_ADD: Add Route: len 200, pid: 0, seq 0, errno 0, flags:<UP,DONE,PINNED> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 10.0.0.0 link#5 255.255.255.0 Note 40 bytes different (52-16 + alignment). However, gateway is still a valid AF_LINK gateway with proper data filled in. It is worth noting that these particular messages (interface routes) are mostly ignored by routing daemons: * bird/quagga/frr uses RTM_NEWADDR and ignores prefix route addition messages. * quagga/frr ignores routes without gateway More detailed overview on how rtsock messages are used by the routing daemons to reconstruct the kernel view, can be found in D22974. Differential Revision: https://reviews.freebsd.org/D24519 |
||
---|---|---|
.. | ||
dest6.c | ||
frag6.c | ||
icmp6.c | ||
icmp6.h | ||
in6_cksum.c | ||
in6_fib.c | ||
in6_fib.h | ||
in6_gif.c | ||
in6_ifattach.c | ||
in6_ifattach.h | ||
in6_jail.c | ||
in6_mcast.c | ||
in6_pcb.c | ||
in6_pcb.h | ||
in6_pcbgroup.c | ||
in6_proto.c | ||
in6_rmx.c | ||
in6_rss.c | ||
in6_rss.h | ||
in6_src.c | ||
in6_var.h | ||
in6.c | ||
in6.h | ||
ip6_ecn.h | ||
ip6_fastfwd.c | ||
ip6_forward.c | ||
ip6_gre.c | ||
ip6_id.c | ||
ip6_input.c | ||
ip6_mroute.c | ||
ip6_mroute.h | ||
ip6_output.c | ||
ip6_var.h | ||
ip6.h | ||
ip6protosw.h | ||
ip_fw_nat64.h | ||
ip_fw_nptv6.h | ||
mld6_var.h | ||
mld6.c | ||
mld6.h | ||
nd6_nbr.c | ||
nd6_rtr.c | ||
nd6.c | ||
nd6.h | ||
pim6_var.h | ||
pim6.h | ||
raw_ip6.c | ||
raw_ip6.h | ||
route6.c | ||
scope6_var.h | ||
scope6.c | ||
sctp6_usrreq.c | ||
sctp6_var.h | ||
send.c | ||
send.h | ||
tcp6_var.h | ||
udp6_usrreq.c | ||
udp6_var.h |