On 17.10.24 20:09, Pablo Neira Ayuso wrote:

On Thu, Oct 17, 2024 at 07:06:51PM +0200, Felix Fietkau wrote:

quoted

On 17.10.24 14:39, Pablo Neira Ayuso wrote:

quoted

On Thu, Oct 17, 2024 at 11:17:09AM +0200, Felix Fietkau wrote:
[...]

quoted

By the way, based on some reports that I received, I do believe that the
existing forwarding fastpath also doesn't handle roaming properly.
I just didn't have the time to properly look into that yet.

I think it should work for the existing forwarding fastpath.

- If computer roams from different port, packets follow classic path,
   then new flow entry is created. The flow old entry expires after 30
   seconds.
- If route is stale, flow entry is also removed.

Maybe I am missing another possible scenario?

I'm mainly talking about the scenario where a computer moves to a different
switch port on L2 only, so all routes remain the same.

I haven't fully analyzed the issue, but I did find a few potential issues
with what you're describing.

1. Since one direction remains the same when a computer roams, a new flow
entry would probably fail to be added because of an existing entry in the
flow hash table.

I don't think so, hash includes iifidx.

I'm talking about the side where the input ifindex remains the same, but 
the output interface doesn't.

quoted

2. Even with that out of the way, the MTK hardware offload currently does
not support matching the incoming switch/ethernet port.
So even if we manage to add an updated entry, the old entry could still be
kept alive by the hardware.

OK, that means probably driver needs to address the lack of iifidx in
the matching by dealling with more than one single flow entry to point
to one single hardware entry (refcounting?).

If we have multiple colliding entries, I think a more reasonable 
behavior would be allowing the newer flow to override the older one.

quoted

The issues I found probably wouldn't cause connection hangs in pure L3
software flow offload, since it will use the bridge device for xmit instead
of its members. But since hardware offload needs to redirect traffic to
individual bridge ports, it could cause connection hangs with stale flow
entries.

I would not expect a hang, packets will just flow over classic path
for a little while for the computer that is roaming until the new flow
entry is added.

If the hardware still handles traffic, but redirects it to the wrong 
destination port, the connection will hang.

- Felix