[dev] Some doubts regarding asynchronous data plane in FRR
sudhanshu22 at gmail.com
Tue Jul 30 06:26:52 EDT 2019
Thanks for the answers. I was looking at the below pull changes.
I had the following questions.
1. I see that there is no place for asynchronous response
in dplane_thread_loop(). As soon as we complete sending routes (contexts),
we start processing response in zdplane_info.dg_results_cb(). By
asynchronous response, we mean that once provider calls its work function,
it needs to wait for the reply. The reply will come later.
2. dplane_provider_enqueue_to_zebra() not called anywhere. Can we call
this, on receiving asynchronous update from provider with proper op-code.
How to get the ctx in this function. Will it be available in rib_dplane_q ?
3. I did not understand ctx->zd_notif_provider.
On Mon, Jul 29, 2019 at 6:29 PM Mark Stapp <mjs at voltanet.io> wrote:
> thanks for your good questions - some answers inline:
> On Sat, Jul 27, 2019 at 11:55 PM sudhanshu kumar <sudhanshu22 at gmail.com>
>> I have 2 doubts regarding asynchronous dataplane implementation in FRR.
>> 1. When there are multiple dplanes, each can process the same route
>> context and modify the status in the context. But while
>> processing rib_process_after(), we only consider the status returned by the
>> last processed provider. Is this correct? We should, in this case, consider
>> status returned by all the providers. If all of them return success, then
>> only, we should consider the status as success in rib_process_after().
> One correction - we actually consider an update to be an 'error' as soon
> as an error status is set by a provider. so we are capturing the _first_
> error, not the last status.
> We've had conversation about this from time to time, but there are several
> related/entangled issues. the core, platform-neutral zebra code is only
> prepared to process one result. given the way that zebra (and frr) are
> being used in most cases, in systems where there is only a single FIB, a
> single dataplane, that makes sense and is appropriate. if more complex
> systems become more common, we may want to revisit how we capture and
> report status. at the very least, it may make sense to be able to report
> more complex results through the management system.
>> 2. Currently, zebra fpm interaction happens in rib context using hook. I
>> would like to know why this was done ? Can this be made as a separate
>> dplane ?
> we've talked about this a bit too. moving the fpm messaging to be a dplane
> plugin would be pretty natural (since it's one-way, outgoing only). it just
> hasn't been a priority for anyone yet. I expect it will happen, and it
> would allow some simplification of zebra code in some places.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev