On 2025-09-25 20:55, David Gibson wrote:
On Thu, Sep 25, 2025 at 09:14:42AM -0400, Jon Maloy wrote:
On 2025-09-25 02:36, David Gibson wrote:
On Wed, Sep 24, 2025 at 06:18:52PM -0400, Jon Maloy wrote:
[...]
I experimented a bit with this. My test program is a simple UDP client-server pair, exchanging first 3 UDP messages client->server, followed by 3 messages server->client.
With the client on the guest, and server outside? How is the outside machine arranged - is it a physically separate host? A bridged VM or container on the same host? Something else?
It is a physically separate host.
First, I changed the main() loop a bit, so that netlink events are handled before all other events, if any. (Basically, I added an extra loop before the main loop, only handling netlink events, before moving on to the main loop (where netlink events had been excluded.) This should secure absolute priority of netlink events before any other events. As you will see below, this made no difference to the scenarios I describe.
Drat.
1: When starting the container, I notice that there is no subscription event in PASTA, even though I can see the entry for the remote host is present in the host's ARP table. There is never any event coming up even if I wait for 10+ minutes.
Huh.... do we need to do something to ensure we get events for existing entries in the host ARP table, not just ones that are added or updated after we're running?
It doesn't seem to be possible,
It actually *is* possible, and I just implemented it. It doesn't solve all problems, but makes a huge difference. I will add it in v10.
Can we do an RTM_GETNEIGH, with no address specified? It's something like that we do to get all our links and addresses in other places.
but even if it were it wouldn't help us much if the entry isn't here, which is also a problematic case. See below.
2: The first UDP is attempted sent from the guest. An ARP request is sent to PASTA, and responded to with the 9a:9a: address.
Maybe we still need to explicitly ask for an ARP resolution when the guest ARPs.
I think so. If we limit this to ARP and NDP, this should be unproblematic.
I just realised this is harder than I thought, though. At least if we want to get the right answer for the first guest ARP. It's not just a netlink request, we'd need to wait for the host to ARP, which means timeouts, and state we need to track, and ...
Yes. I think with the above it is as good as it gets, and it isn't bad. ///jon