[dev] FRR Zebra/FPM interactions

Donald Sharp sharpd at cumulusnetworks.com
Wed Oct 25 09:08:15 EDT 2017


Thorvald -

Hi!  I'm Donald Sharp, I'm working on FRR, I'm discussing with you this PR:

https://github.com/FRRouting/frr/pull/1350

First I'd like to apologize for the slow response to your enquiries on the PR.

I decided to reach out directly to you because I feel like email might
be a bit better medium to talk about what our plans are and to
describe what I see the future of zebra is.  Our plans are not
currently set in stone but we do have some broad strokes of what we
want to accomplish:

1) Separate the south bound API in such a manner that we use a
starting function call.  Currently both the FPM interactions and
zebra/rt.h are our south bound interfaces

As an example rib_install_kernel does this:

            rib_install_kernel

                     hook_call (rib_update)   -> FPM interactions
                     kernel_route_rib             -> Rib install for
kernel we are working on.
                     if (success)
                           Set some values

We want it to do this:

            rib_install_kernel

                     kernel_route_rib        ->          List of hooks to call:

     FPM Interactions

     Rib install for kernel we are working on

     Anything else we add as a rib_update hook

if (success)

      Call kernel_route_rib_success() function

Now rinse/repeat this for all rt.h southbound api's.

2) Separate processing of southbound api into it's own true pthread(
not lib/thread.h ):
Currently the FPM has a TAILQ_ENTRY(rib_dest_t_) in rib_dest_t(rib.h)
to track and process FPM install/deletes/whatever..   I would like to
convert this data structure to the control point for what has been
communicated south bound.  Then allow the southbound api's to bundle
the installation into whatever however they would like to do so in a
timeframe that it would like to do so as well.  I think this would
allow us to do things like bundling of netlink messages to the kernel.
Kernel insertion on linux as it stands is absurdly slow and needs to
be sped up.

3) Arbitrary hook levels:

We would also like the ability for FPM interactions and Rib install
hooks have the ability to have sub hooks as well if they would like to
as well.  As an example the rib interactions could have a route-map
application hook before passing to the kernel.

4) Allow which hooks to be used via a control mechanism( this is what
you were really asking for ) to control who get's called.  As you
noticed it would be nice to have a way to control which soutbound
hooks are actually installed and used.

Now where to start?  I personally think we need to start with #1.  #2
and #4 will flow from that imo.

donald

PS - If you would like more immediate access than email, we use a
public slack (frrouting.slack.com) if you would like an invite please
let me know.



More information about the dev mailing list