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 4D42DD21694 for ; Tue, 15 Oct 2024 12:32:21 +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=XieAo9HL5vyNwm1c3ghYumY3Fx+xJStWHjWEsuxERvg=; b=Z/Bc+ysBfknagvFux6cgkRF46Z 60k+7IjWoopGbu4TiU6j6Apsf5YeI/JF94rue8TfK6Dlo0vB8Q5bNTg6zbvE1Y1G3lbLtlpTFrlrn ONI+t1nLQ1om1mtVCWeoecM/5y6OYZI1It5EqdaWmBB5hqfESTMClX34zAugCF02oXDzoX7B2coF+ YOalfLArAbIZgvg4Vtnf2wN19z1R9uiuEXreTQ+ziqSBYyU3jnN+OQP35aAYZdn6Pxaot1h9J9vVu 7L9moJTnL20IRdAXAZmybnfVBhbHqnh5sLtZBQCh8gjbfSiCoCp3MiC/vsL3jgsm531PXlFda3N4Q B5Y3a7cA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t0gif-00000008B6Q-2mkt; Tue, 15 Oct 2024 12:32:09 +0000 Received: from nbd.name ([46.4.11.11]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t0gUD-0000000889m-3tOW; Tue, 15 Oct 2024 12:17:15 +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=XieAo9HL5vyNwm1c3ghYumY3Fx+xJStWHjWEsuxERvg=; b=LQRJxS3d8EEzk5CygKZkzSHCTs lXK+k6n8WMjYXlQyvTMXFODG+6BILFSq1lndW23xP5oHk3beQYvFwW136ysQoPwnWVT/NUGA6a4FN 5J+hbozH7mJddHnpR+bbd6Wg0z8AA1u/ONYUNC1pLVaqilwRs112O1yfMCeA2Xm6Wc5E=; Received: from p54ae9bfc.dip0.t-ipconnect.de ([84.174.155.252] helo=nf.local) by ds12 with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1t0gTm-0098D2-11; Tue, 15 Oct 2024 14:16:46 +0200 Message-ID: <0b0a92f2-2e80-429c-8fcd-d4dc162e6e1f@nbd.name> Date: Tue, 15 Oct 2024 14:16:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC v1 net-next 00/12] bridge-fastpath and related improvements To: Eric Woudstra , Nikolay Aleksandrov , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Pablo Neira Ayuso , Jozsef Kadlecsik , Roopa Prabhu , Matthias Brugger , AngeloGioacchino Del Regno , Jiri Pirko , Sebastian Andrzej Siewior , Lorenzo Bianconi , Frank Wunderlich , Daniel Golle Cc: 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> 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-20241015_051714_003375_E800DEB0 X-CRM114-Status: GOOD ( 14.51 ) 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 Hi Eric, On 14.10.24 20:29, Eric Woudstra wrote: > It would be no problem for me to change the subject and body, if you > think that is better. > > The thing is, these patches actually make it possible to set up a fully > functional software fastpath between bridged interfaces. Only after the > software fastpath is set up and functional, it can be offloaded, which > happens to by my personal motivation to write this patch-set. > > If the offload flag is set in the flowtable, the software fastpath will > be offloaded. But in this patch-set, there is nothing that changes > anything there, the existing code is used unchanged. FWIW, a while back, I also wanted to add a software fast path for the bridge layer to the kernel, also with the intention of using it for hardware offload. It wasn't accepted back then, because (if I remember correctly) people didn't want any extra complexity in the network stack to make the bridge layer faster. Because of that, I created this piece of software: https://github.com/nbd168/bridger It uses an eBPF TC classifier for discovering flows and handling the software fast path, and also creates hardware offload rules for flows. With that, hardware offloading for bridged LAN->WLAN flows is fully supported on MediaTek hardware with upstream kernels. - Felix