The MSDN entry is really unclear. It says that it sends an ARP request, if necessary. I cannot find anything in the entry that says whether, if it sends an ARP request, it waits for a reply.
However, this stackoverflow entry implies that it does wait for a reply: https://stackoverflow.com/questions/43626184/any-way-to-change-the-behavior-of-synchronous-windows-api-sendarp I think that's probably unacceptable because blocking the OVS main thread will break lots of stuff. If it's necessary to block for ARP resolution, then I think it will have to happen in a thread dedicated to that purpose. On Thu, May 24, 2018 at 03:13:58PM +0000, Sairam Venugopal wrote: > This is the snippet from MSDN: > https://msdn.microsoft.com/en-us/library/windows/desktop/aa366358(v=vs.85).aspx > > The SendARP function is used to request the physical hardware address > (sometimes referred to as the MAC address) that corresponds to a specified > destination IPv4 address. If the information requested is not in the ARP > table on the local computer, then the SendARP function will cause an ARP > request to be sent to obtain the physical address. If the function is > successful, the physical address that corresponds to the specified > destination IPv4 address is returned in the array pointed to by the pMacAddr > parameter. > > I don't think this would end up blocking every other thread in OVS. I > might've relayed this information incorrectly. There isn't an argument to > specify timeout for the SendArp function. > > Thanks, > Sairam > > On 5/23/18, 1:19 PM, "Ben Pfaff" <[email protected]> wrote: > > On Fri, May 18, 2018 at 03:16:43PM -0700, Sairam Venugopal wrote: > > IPFIX templates and flow packets are silently dropped when a > corresponding > > ARP entry is missing for the Collector. The fix is to explicitly > trigger an > > ARP request before sending UDP packets to the collector. > > > > Making changes in Windows to maintain the destination IP address as part > > of the Collector Structure. Since the SendARP is a blocking call, we do > > not necessarily need to check for a response before sending the IPFIX > > packets. Keeping the fix specific to Windows since this behavior cannot > be > > reproduced in Linux. > > When you say that SendARP is a blocking call, do you mean that it sends > a packet and then waits for a response? That will delay everything else > happening in the OVS main thread for an arbitrary amount of time. > Usually this is not acceptable. > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
