[PATCH RFC v1 net-next 00/12] bridge-fastpath and related improvements

[Felix Fietkau]

On 17.10.24 20:09, Pablo Neira Ayuso wrote:
> On Thu, Oct 17, 2024 at 07:06:51PM +0200, Felix Fietkau wrote:
>> On 17.10.24 14:39, Pablo Neira Ayuso wrote:
>> > On Thu, Oct 17, 2024 at 11:17:09AM +0200, Felix Fietkau wrote:
>> > [...]
>> > > 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.

>> 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.

>> 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