netmap: Reply to ARP requests from gateway for scan source IPs #807
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In netmap mode, the OS network stack never gets to see incoming packets unless we explicitly forward them to the host rings; hence the kernel will not be responding to ARP requests. To remove the need for static ARP entries on the gateway, respond to ARP requests from the gateway for any of the source IPs of the scan.
The recv thread can now submit packets for sending to send thread 0 via a zqueue. This is used to respond to ARP requests that arrive after having let loose the send threads. While still waiting for end-to-end connectivity with
--netmap-wait-ping
, ARP requests are responded to by sending directly from the recv thread, just like the ICMP Echo requests.I did not see any significant netmap perf change from this at 10 GbE.
Tested on both FreeBSD and Linux. Verified to correctly respond both to arping, as well as to real ARP by deleting ARP entries from the gateway's ARP table and observing the ARP table getting repopulated as well as packets on the wire.