Re: [vpp-dev] Neighbor DUMP Takes Forever
On Wed, Nov 8, 2017 at 12:37 PM, Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) wrote: > 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. > Yep. I get it. I just botched it. Sorry. > HTH, > Klement > Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Neighbor DUMP Takes Forever
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
Re: [vpp-dev] Neighbor DUMP Takes Forever
On Wed, Nov 8, 2017 at 12:25 PM, Jon Loeliger wrote: > Hi Folks, > > OK, maybe the Neighbor DUMP doesn't literally take forever. > But it sure does take too long! Here is the problem: > The problem appears to be PEBCAK. jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Neighbor DUMP Takes Forever
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
