Re: [PATCH v9 9/9] arp/ndp: send gratuitous ARP / unsolicitated NA when MAC cache entry added

[Jon Maloy <jmaloy@redhat.com>]

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

>