Skip to content

Have shorter locks while dumping routing tables #492

@AltraMayor

Description

@AltraMayor

cps/rd.c:rd_getroute(), gk/fib.c:list_ipv4_fib_entries(), and gk/fib.c:list_ipv6_fib_entries() hold a write lock over the entire FIB table for the whole duration of the time needed to dump the FIB table. For cps/rd.c:rd_getroute() in particular, this time even depends on the routing daemon; see cps/rd.c:sendto_with_yield() for details. These long-held locks can cause hiccups in the CPS and dynamic configuration blocks.

A solution is to review the LPM iterators to make sure that they only require the lock while the entries are being inspected. Thus, the functions above could hold the lock to list a maximum number of entries (e.g. cps/rd.c:rd_getroute() could hold the lock until a Netlink batch is full), release the lock, transmit the obtained batch, require the lock again, and repeat this loop until the table is fully listed. Not only does this solution reduce the time that the lock is held, but it also maximizes the chances that rte_spinlock_lock_tm() will be able to employ the hardware memory transaction instead of falling back to a spinlock.

Metadata

Metadata

Assignees

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions