]> git.ipfire.org Git - thirdparty/ipxe.git/commit
[ipoib] Attempt to generate ARPs as needed to repopulate REMAC cache
authorMichael Brown <mcb30@ipxe.org>
Mon, 29 Jun 2015 13:50:16 +0000 (14:50 +0100)
committerMichael Brown <mcb30@ipxe.org>
Mon, 29 Jun 2015 13:50:16 +0000 (14:50 +0100)
commit8829634bd7188bdfa5528421a8bbecf39c498f40
tree1b5f2aa8169c91c97b286632f3119228ea1eb32e
parente213a008ca448c41f617d4565e0473ca705e69b3
[ipoib] Attempt to generate ARPs as needed to repopulate REMAC cache

The only way to map an eIPoIB MAC address (REMAC) to an IPoIB MAC
address is to intercept an incoming ARP request or reply.

If we do not have an REMAC cache entry for a particular destination
MAC address, then we cannot transmit the packet.  This can arise in at
least two situations:

 - An external program (e.g. a PXE NBP using the UNDI API) may attempt
   to transmit to a destination MAC address that has been obtained by
   some method other than ARP.

 - Memory pressure may have caused REMAC cache entries to be
   discarded.  This is fairly likely on a busy network, since REMAC
   cache entries are created for all received (broadcast) ARP
   requests.  (We can't sensibly avoid creating these cache entries,
   since they are required in order to send an ARP reply, and when we
   are being used via the UNDI API we may have no knowledge of which
   IP addresses are "ours".)

Attempt to ameliorate the situation by generating a semi-spurious ARP
request whenever we find a missing REMAC cache entry.  This will
hopefully trigger an ARP reply, which would then provide us with the
information required to populate the REMAC cache.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
src/drivers/net/ipoib.c
src/include/ipxe/arp.h
src/net/arp.c