<div dir="ltr"><div dir="ltr">I'll try to answer in-line:<br></div><br><div class="gmail_quote"><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>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></blockquote><div><br></div><div>We don't want the dataplane pthread to "wait" - we don't want to block or stop doing work in that pthread. The expectation is that a provider plugin would use the existing event-delivery mechanisms in libfrr (see lib/thread.h) to schedule callbacks if the plugin needs to do asynchronous work. That's why the 'thread_master' is available to the plugins. It's also possible for a plugin to spawn and manage its own pthread - that's also supported. the plugin would need to specify that its in- and out-bound queues need to use a lock; there's an api for that too.<br></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. 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></blockquote><div><br></div><div>Yes, this exists so that a plugin can receive some information from ... somewhere, create a context, and enqueue it for processing in the main zebra context. There are a range of apis to create and manipulate context objects - route and lsp contexts in particular at this time. And of course if there's some context-related api that should be added, feel free to ask about it (or offer a PR).</div><div><br></div><div>The background for this is that my company, at least, runs frr on a different platform (different hardware, different OS) than the actual packet-forwarding hardware. We run frr in cloud-hosted containers, but use whitebox switches to perform actual transit forwarding. We use a plugin to convey route (and lsp, etc.) changes towards the forwarding switches, and that plugin can also receive updates as the switches detect relevant events that affect routes.<br></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></div><div>3. I did not understand ctx->zd_notif_provider. </div><div><br></div></div></blockquote><div><br></div><div>The notification path is entirely optional, and the default "kernel" plugin/provider does not use it (currently). The basic case is this:</div><div><br></div><div> 1. some part of the dataplane is external, running in a different context (different host, different OS) than zebra itself</div><div>2. the external dataplane detects some change to a route - a nexthop transitions between useable or installed and unuseable. that event is sent to a zebra plugin.</div><div>3. the plugin creates a notification context for the route, populates it with information about the current status, and enqueues it to zebra</div><div>4. zebra changes its internal datastructures to reflect what has happened at the remote dataplane</div><div>5 a. it may be that we want the local kernel to reflect the same state as the remote dataplane. in that case, we trigger a kernel update based on the notification context object. in order to retain a single code path for the delivery and processing of the context objects, that context cycles through the dataplane subsystem again.</div><div>5 b. the originating plugin can detect that the context does not need to be processed by it (it _is_ the 'notif_provider')<br></div><div>5 c. the kernel plugin can perform an update based on the context<br></div><div>5 d. when the context returns back to the zebra main pthread and the code in zebra_rib.c sees that context, it can detect that its internal datastructures have already been updated, and it finishes with the context immediately.</div><div><br></div><div>Regards,</div><div>Mark<br></div><div><br></div></div></div>