From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 95B9ED3C526 for ; Thu, 17 Oct 2024 17:16:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=m1RLVmWZRpVwJRzpSh3rndfAqydCA0xQpFJqAnYi0pM=; b=SxcdOcAviYUVccjL2U89HrXVoV Y+bdjadzAEM4o1awmbGgGP74QSF6zZs4h0/SaXK77QqYewqjuauY6rImATa4t3CmcZUgy8FVhtWYz MDxMteqgIJR8tWz80d7ykChmToPMGIDAxXCRmPl19UdH9RYu/XWcsKb4rSGbAEi9ikeZavdJF/6oC cZ2pRprZHl/6JLRMUDGBWLbREsuyrsV0LdRJgJ4lfV2zJTQprac/PllXsBKcZb9hNjV5QZNswPvbj dye74nrUdi5JNhNsJSh+2/TLRLi+3YNf9MRQ2zAoAk2+OGqzEoDmEzQY6cTW+HXllrTskJ9HJ8+/4 xYRX23Mg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1U6W-0000000FgQa-1XrL; Thu, 17 Oct 2024 17:16:04 +0000 Received: from nbd.name ([46.4.11.11]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t1Txx-0000000FeVg-3UBa; Thu, 17 Oct 2024 17:07:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbd.name; s=20160729; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=m1RLVmWZRpVwJRzpSh3rndfAqydCA0xQpFJqAnYi0pM=; b=n6AJ/iLqfAT0IJvQR7XfL1e3qR 0Lzs6X6mMsz4RjzDahPcA9umsCpgravM5zz6efj1Gxyy7NSheuaKnv3tTq6CN6I/dOgVxnHmhjzpq nepykm7SO1HHecJjOGiStB4h7pv2v5jjRxege7e1yYaDykRrrkiuRUzRJzdll5dUdt6c=; Received: from p4ff13b65.dip0.t-ipconnect.de ([79.241.59.101] helo=nf.local) by ds12 with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1t1Txc-00AukV-08; Thu, 17 Oct 2024 19:06:52 +0200 Message-ID: Date: Thu, 17 Oct 2024 19:06:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC v1 net-next 00/12] bridge-fastpath and related improvements To: Pablo Neira Ayuso Cc: Eric Woudstra , Nikolay Aleksandrov , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jozsef Kadlecsik , Roopa Prabhu , Matthias Brugger , AngeloGioacchino Del Regno , Jiri Pirko , Sebastian Andrzej Siewior , Lorenzo Bianconi , Frank Wunderlich , Daniel Golle , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, bridge@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org References: <20241013185509.4430-1-ericwouds@gmail.com> <9f9f3cf0-7a78-40f1-b8d5-f06a2d428210@blackwall.org> <0b0a92f2-2e80-429c-8fcd-d4dc162e6e1f@nbd.name> <137aa23a-db21-43c2-8fb0-608cfe221356@gmail.com> From: Felix Fietkau Content-Language: en-US Autocrypt: addr=nbd@nbd.name; keydata= xsDiBEah5CcRBADIY7pu4LIv3jBlyQ/2u87iIZGe6f0f8pyB4UjzfJNXhJb8JylYYRzIOSxh ExKsdLCnJqsG1PY1mqTtoG8sONpwsHr2oJ4itjcGHfn5NJSUGTbtbbxLro13tHkGFCoCr4Z5 Pv+XRgiANSpYlIigiMbOkide6wbggQK32tC20QxUIwCg4k6dtV/4kwEeiOUfErq00TVqIiEE AKcUi4taOuh/PQWx/Ujjl/P1LfJXqLKRPa8PwD4j2yjoc9l+7LptSxJThL9KSu6gtXQjcoR2 vCK0OeYJhgO4kYMI78h1TSaxmtImEAnjFPYJYVsxrhay92jisYc7z5R/76AaELfF6RCjjGeP wdalulG+erWju710Bif7E1yjYVWeA/9Wd1lsOmx6uwwYgNqoFtcAunDaMKi9xVQW18FsUusM TdRvTZLBpoUAy+MajAL+R73TwLq3LnKpIcCwftyQXK5pEDKq57OhxJVv1Q8XkA9Dn1SBOjNB l25vJDFAT9ntp9THeDD2fv15yk4EKpWhu4H00/YX8KkhFsrtUs69+vZQwc0cRmVsaXggRmll dGthdSA8bmJkQG5iZC5uYW1lPsJgBBMRAgAgBQJGoeQnAhsjBgsJCAcDAgQVAggDBBYCAwEC HgECF4AACgkQ130UHQKnbvXsvgCgjsAIIOsY7xZ8VcSm7NABpi91yTMAniMMmH7FRenEAYMa VrwYTIThkTlQzsFNBEah5FQQCACMIep/hTzgPZ9HbCTKm9xN4bZX0JjrqjFem1Nxf3MBM5vN CYGBn8F4sGIzPmLhl4xFeq3k5irVg/YvxSDbQN6NJv8o+tP6zsMeWX2JjtV0P4aDIN1pK2/w VxcicArw0VYdv2ZCarccFBgH2a6GjswqlCqVM3gNIMI8ikzenKcso8YErGGiKYeMEZLwHaxE Y7mTPuOTrWL8uWWRL5mVjhZEVvDez6em/OYvzBwbkhImrryF29e3Po2cfY2n7EKjjr3/141K DHBBdgXlPNfDwROnA5ugjjEBjwkwBQqPpDA7AYPvpHh5vLbZnVGu5CwG7NAsrb2isRmjYoqk wu++3117AAMFB/9S0Sj7qFFQcD4laADVsabTpNNpaV4wAgVTRHKV/kC9luItzwDnUcsZUPdQ f3MueRJ3jIHU0UmRBG3uQftqbZJj3ikhnfvyLmkCNe+/hXhPu9sGvXyi2D4vszICvc1KL4RD aLSrOsROx22eZ26KqcW4ny7+va2FnvjsZgI8h4sDmaLzKczVRIiLITiMpLFEU/VoSv0m1F4B FtRgoiyjFzigWG0MsTdAN6FJzGh4mWWGIlE7o5JraNhnTd+yTUIPtw3ym6l8P+gbvfoZida0 TspgwBWLnXQvP5EDvlZnNaKa/3oBes6z0QdaSOwZCRA3QSLHBwtgUsrT6RxRSweLrcabwkkE GBECAAkFAkah5FQCGwwACgkQ130UHQKnbvW2GgCeMncXpbbWNT2AtoAYICrKyX5R3iMAoMhw cL98efvrjdstUfTCP2pfetyN In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241017_100715_168942_A08828E0 X-CRM114-Status: GOOD ( 18.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. 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. 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. There might be other issues as well, but this is what I could come up with on short notice. I think in order to properly address this, we should probably monitor for FDB / neigh entry changes somehow and clear affected flows. Routes do not become stale in my scenario, so something else is needed to trigger flow entry removal. - Felix