Hi all, I'm using the `arping` plugin's binary API (vl_api_arping_t) from a control-plane agent and I'd like to understand the intended design, because it appears to serialize unrelated API calls.
Environment: - VPP version: <e.g. 24.02 / commit ...> - Plugin: src/plugins/arping (arping.api / arping_api.c / arping.c) Observed behavior: When my agent issues `arping` (is_garp=0, i.e. a probe) to trigger neighbor resolution for a next hop, the API handler path vl_api_arping_t_handler -> arping_run_command -> arping_neighbor_probe_dst: 1. enables the "arping-input" feature on the "arp" arc (vlib_worker_thread_barrier_sync/release), 2. sends the ARP request, then 3. blocks in a loop `while (reply_count < send_count && wait_count < 10) vlib_process_suspend(vm, 0.1);` waiting up to ~1s for the reply, 4. disables the feature again (another barrier sync). Because this runs in the main VPP API/vlib process context, suspending it stalls processing of subsequent API messages. In our case a `create_vlan_subif` (and route programming) issued right after gets delayed by up to ~1s per arping call. During bulk provisioning (hundreds of next hops, many of them addresses that never reply, so each hits the full 1s timeout) this serializes the whole API pipeline and provisioning slows down dramatically. Notably, our use case does not need the reply at all — the API reply only carries reply_count, and we just want to *trigger* resolution so the neighbor entry gets populated by the normal arp-reply path. We don't consume the learned MAC. Questions: 1. Is the synchronous, reply-waiting behavior in the API handler intentional? What's the rationale for blocking inside the handler rather than returning immediately after sending the request? 2. Is there a recommended non-blocking way to trigger ARP/ND resolution for a given (sw_if_index, address) from the control plane — e.g. an ip-neighbor "probe" primitive, or simply relying on on-demand resolution when the adjacency is incomplete? 3. Would a "no-wait" / fire-and-forget flag on the arping API (send the request, skip the feature enable/disable barrier syncs and the suspend loop, return immediately) be acceptable in principle? I'm happy to prepare a patch. 4. More generally, is there a preferred pattern for bulk pre-resolution of many neighbors without stalling the API thread? Thanks for any guidance
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27139): https://lists.fd.io/g/vpp-dev/message/27139 Mute This Topic: https://lists.fd.io/mt/120842774/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
