<div dir="ltr">Hi,<div>Thanks for the answers. I was looking at the below pull changes.</div><div><a href="https://github.com/FRRouting/frr/pull/4228/commits">https://github.com/FRRouting/frr/pull/4228/commits</a> </div><div><br></div><div>I had the following questions.</div><div>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.</div><div>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 ?<br></div><div>3. I did not understand ctx->zd_notif_provider. </div><div><br></div><div>Thanks,</div><div>Sudhanshu</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 29, 2019 at 6:29 PM Mark Stapp <<a href="mailto:mjs@voltanet.io" target="_blank">mjs@voltanet.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div>thanks for your good questions - some answers inline:<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 27, 2019 at 11:55 PM sudhanshu kumar <<a href="mailto:sudhanshu22@gmail.com" target="_blank">sudhanshu22@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><div>I have 2 doubts regarding asynchronous dataplane implementation in FRR.</div><div>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().</div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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 ?</div><div><br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Mark<br></div></div></div>
</blockquote></div>