You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks to pull requests #594 and #628, Gatekeeper has RIB and FIB libraries that require little code adjustments to handle IPv4 and IPv6. The importance of higher levels of code reuse is direct: less code to write and maintain, and lower effort to verify the correctness and to test. The gains brought by the new RIB and FIB libraries can be extended if Gatekeeper adopts a generalized way to handle IP addresses.
Gatekeeper currently relies on struct in_addr and struct in_addr to store IPv4 and IPv6, respectively. This approach requires different ways to use and access the addresses. For example, consider the functions lookup_fib_bulk() and lookup_fib6_bulk(), both in gk/main.c. Although flows are passed to these functions using the generalized struct ip_flow, accessing the destination addresses is not identical: (const uint8_t *)&flows[i]->f.v4.dst.s_addr vs flows[i]->f.v6.dst.s6_addr. For reference, here is the definition of struct ip_flow:
A solution to this problem is to adopt rib_address_t to store all IP addresses. With this new approach, struct ip_flow would become as follows:
structip_flow {
/* IPv4 or IPv6. */uint16_tproto;
/* Addresses in network order. */rib_address_tsrc_no;
rib_address_tdst_no;
};
Of course, a number of support functions are necessary to handle these addresses without distinction. And some of these support functions are already available in the code of the RIB and FIB libraries. For example: read_addr(), write_addr(), and address_to_str().
Once IP addresses are generalized, one can refactor the codebase to leverage code reuse. For example, struct gk_lpm, which encapsulates the routing table for IPv4 and IPv6 in the GK block, could be broken up into two instances of a new struct gk_lpm. The new struct gk_lpm would be as follows:
structgk_lpm {
/* Use a spin lock to edit the FIB table. */rte_spinlock_tlock;
/* The RIB and FIB. */structfib_headfib;
/* The FIB table that decides the actions on packets. */structgk_fib*fib_tbl;
/* * Indexes of the last FIB entries allocated at @fib_tbl and @fib_tbl6. * get_empty_fib_id() is the only function that uses these fields. */uint32_tlast_index;
/* The number of entries in field @fib_tbl. */uint32_tnum_fib;
};
Notice that, since there will be two instances of the new struct gk_lpm, there will a lock for IPv4 and a lock for IPv6. In addition, the field num_fib was added to remove dependence on fields max_num_ipv4_rules and max_num_ipv6_rules of struct gk_config.
The new struct gk_lpm would enable lookup_fib_bulk() and lookup_fib6_bulk() to become a single function. Code everywhere in the codebase has potential for deduplication using a similar strategy; especially code in gk/rt.c and code that relies on struct ipaddr.
The text was updated successfully, but these errors were encountered:
Thanks to pull requests #594 and #628, Gatekeeper has RIB and FIB libraries that require little code adjustments to handle IPv4 and IPv6. The importance of higher levels of code reuse is direct: less code to write and maintain, and lower effort to verify the correctness and to test. The gains brought by the new RIB and FIB libraries can be extended if Gatekeeper adopts a generalized way to handle IP addresses.
Gatekeeper currently relies on
struct in_addr
andstruct in_addr
to store IPv4 and IPv6, respectively. This approach requires different ways to use and access the addresses. For example, consider the functionslookup_fib_bulk()
andlookup_fib6_bulk()
, both ingk/main.c
. Although flows are passed to these functions using the generalizedstruct ip_flow
, accessing the destination addresses is not identical:(const uint8_t *)&flows[i]->f.v4.dst.s_addr
vsflows[i]->f.v6.dst.s6_addr
. For reference, here is the definition ofstruct ip_flow
:A solution to this problem is to adopt
rib_address_t
to store all IP addresses. With this new approach,struct ip_flow
would become as follows:Of course, a number of support functions are necessary to handle these addresses without distinction. And some of these support functions are already available in the code of the RIB and FIB libraries. For example:
read_addr()
,write_addr()
, andaddress_to_str()
.Once IP addresses are generalized, one can refactor the codebase to leverage code reuse. For example,
struct gk_lpm
, which encapsulates the routing table for IPv4 and IPv6 in the GK block, could be broken up into two instances of a newstruct gk_lpm
. The newstruct gk_lpm
would be as follows:Notice that, since there will be two instances of the new
struct gk_lpm
, there will a lock for IPv4 and a lock for IPv6. In addition, the fieldnum_fib
was added to remove dependence on fieldsmax_num_ipv4_rules
andmax_num_ipv6_rules
ofstruct gk_config
.The new
struct gk_lpm
would enablelookup_fib_bulk()
andlookup_fib6_bulk()
to become a single function. Code everywhere in the codebase has potential for deduplication using a similar strategy; especially code ingk/rt.c
and code that relies onstruct ipaddr
.The text was updated successfully, but these errors were encountered: