Hi Jon, the usual way to deal with possible-empty result sets is to wrap the call with a control-ping.
1.) send control-ping 2.) send e.g. sw_interface_dump 3.) start collecting sw_interface_details responses (if any) 4.) once control-ping reply is received, you know that there will be no more responses to the sw_interface_dump call. This approach is used by all the existing API bindings, python, C VAPI, C++ VAPI... There have been proposals to have this logic built-in, but it doesn't seem to have happened so far.. HTH, Klement Quoting Jon Loeliger (2017-11-08 19:25:03) > Hi Folks, > OK, maybe the Neighbor DUMP doesn't literally take forever. > But it sure does take too long! Here is the problem: > When one goes to DUMP the Neighbor tables, one has no idea which interface > might have ARP/NDP entries on them. So one determines the total number of > interfaces, and then one iterates over them one at a time asking for an > IP_NEIGHBOR_DUMP of each sw_if_index and AF combination. > That's all fine. The problem is that the DUMP response DETAILS never come > for > interfaces that have NO entries. So the message handling times-out > instead. With > a one-second timeout on each (interface, AF) pair, it takes 2 seconds per > IF. > It makes for a very slow process to determine the ARP/Neighbor tables. > This used to be a problem in the NAT DUMP as well, but that was fixed. I > don't > recall how off-hand, but at least one solution would be to always reply, > and if a > bogus entry is needed, do that. Use a detail with a sw_if_index = ~0 if > necessary. > (Yeah, the ip_neighbor_t detail should be returning the sw_if_index too > anyway.) > Maybe something like that? > Oh, the reason that you never see this problem with vppctl is that it > doesn't > use the API. It goes straight to internal data structures instead. > Thanks, > jdl _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
