From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82872376497 for ; Fri, 6 Feb 2026 10:34:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770374067; cv=none; b=VlTihEghTdZ9L9n56ldHLFFQCSnryqB3mqFADnyhom6vEB5o9UdXNmILJGza4/lfj26bMCJ59KEB+FJ/K99DrgxsMjdjSyvxkyQvKGkjY0ssEWnBzxzwOE15O6GqPN1Z1Pqnr9Z3h4Vfw/qAKqyyCmTnUXDJRT87+E3LG1pSp34= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770374067; c=relaxed/simple; bh=6OnxLe8EyUUzTBtYYOFz/C0thedtH48VjMALAeoKO+Q=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=sNcJATWy68thlDFwuRe1SYMlZTmhXFiSEDs09dGtgLpnf0/OL6ypxw2irXM1yFGohbBy9av1lvVi+IEKzaSdhmtkJaA4Jm7+T372juDdyrG06fvKUMAnSExIAfgPnov3q9ooiR8PTaoWyPt39tlmwi9mKSh+n+RnTPd0Tl0tJG8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=cogentembedded.com; spf=pass smtp.mailfrom=cogentembedded.com; dkim=pass (2048-bit key) header.d=cogentembedded-com.20230601.gappssmtp.com header.i=@cogentembedded-com.20230601.gappssmtp.com header.b=ZxYieJ6t; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=cogentembedded.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cogentembedded.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cogentembedded-com.20230601.gappssmtp.com header.i=@cogentembedded-com.20230601.gappssmtp.com header.b="ZxYieJ6t" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-435f177a8f7so562504f8f.1 for ; Fri, 06 Feb 2026 02:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cogentembedded-com.20230601.gappssmtp.com; s=20230601; t=1770374066; x=1770978866; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=LHMkTXnKnNt0ryQWtQStRCNfgK5XQzWzGDoLk6H5Ljo=; b=ZxYieJ6t9/kKFV9cSCpsBnpD/AjNohF2pqdWq8gNE+6SAftrNeRe1wgkU57a6caobi 7ei0MucCaK6rGA4SBne2eAwJAB6/hUcO1nYrCtEzusI3YUsOE17kE7cLG2HhyEIx/bcU AUjyKwp0Ja1+he387ixfQHzLZwUnKLXAPsL7o8fnRL3ejORObukWtQtI2CFyhm46G+RO /qrZxlTifatGzg2Q5C2hLRVHIQK/EZ+jdYAIcMLRJuREovcPu+/c6cBo8dls7S3T1TsG n06hpngRDy8FAvSbYEt/fUHAWg851d6fCFqursDW1e/E7GpRN2KxPVlHaGdiOw1I/KrG VO6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770374066; x=1770978866; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LHMkTXnKnNt0ryQWtQStRCNfgK5XQzWzGDoLk6H5Ljo=; b=NYDQm2x1NWvrS0zyZo4v/biLxwoKaW2V4+d+xoxOOetIthWYrW6NHtIp4xbenE6FLe A0pwCwccRcwVRbvmjN1qu0s2Hycw64m5DOYc7uY9ErOHhWs3hCxKQEOs/DNPw7+7GJop hRoE6DybT4C+xklEI84MjrIPIZtA4BTnmcNsDyOs48zEHyAkH/q0gi8g+NfvPEI/XlaX T0yvIhgy0BNzlLZhw8LcdhT/lcX2MZfuWRNS785mVIgcaz7/VjoVb9DZ/MTxPfq2qveB N6marPg0+jRoEMClVkH6CLr9CiM712U+lnRalUZIz0jB0x4CZupnHjFlNhDldz6UPCaG C06g== X-Forwarded-Encrypted: i=1; AJvYcCWcYeS2vRPKQWRr7tNKIzJRRmSKvqb3M8Mo81UV1EVODGpNf0/wEff+aupBl8wEYjsxtsPeVctcknGdxVw=@vger.kernel.org X-Gm-Message-State: AOJu0Yw6haSneGrgw22t+SzLfc9ilW/pxKWBEgE3haS9cEhwE1iLJb1m RO+XbAg2479LN5ivRfZPdQ686T+wogoi3vDsrTscQgY6suCjTu59i1ltwTqBVOM6cSg= X-Gm-Gg: AZuq6aJQXnvck3QtH/KCqisF7jBpwtEl5ZmenP2Jhw22Ie5c7fuHPEfrYUymIgKGVJG F9wdnfDSwuo2XUUc0YrLAzL73VjX13qaocyFIjzvt9rnKCrG+9bqOMH560rSFG1gQWmFrhpspy+ cYUTeG22jzWnWkU/a1amNFdVqzZND1BLMv4rx920SuqLKFDbUkBRAnoj6IZYm9sYBAT4k8hy4CO 7nPYm+1Ge+RXvQoN8eIHBeUhbZQtI96cmXsSaij0grAaSyY1vBem1k1WvGu8U3gmf2GzG+pWCQ7 2G/gltoiGBRgIAeU+dLumFLNbUOS+g44uSESezWKLL6r5orsH8BuP+sT0+FYLcNswKt4fA2uJFY wwPQSei/BFCUbDpumWE9O/s5y+7hPxMv8k9UzGsaeGbV9KsgAzM51dgS0f5u9LPtChu7JekKlw2 yIMcT7UuZmSpSSJLpdga+LxO1u++BVc2j8CRsn X-Received: by 2002:a05:600c:348c:b0:480:462e:d640 with SMTP id 5b1f17b1804b1-4832022f781mr35081625e9.36.1770374065755; Fri, 06 Feb 2026 02:34:25 -0800 (PST) Received: from ?IPV6:2a02:810a:b98:a000::159a? ([2a02:810a:b98:a000::159a]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-436296bd1c9sm4602013f8f.15.2026.02.06.02.34.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Feb 2026 02:34:25 -0800 (PST) Message-ID: <1aa615e2-1297-40a9-b7c4-beb943996721@cogentembedded.com> Date: Fri, 6 Feb 2026 11:34:24 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Nikita Yushchenko Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine To: Michael Dege , Yoshihiro Shimoda , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: "netdev@vger.kernel.org" , "linux-renesas-soc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Christian Mardmoeller , Dennis Ostermann References: <20260205-fix-offloading-statemachine-v1-1-640224a531d0@renesas.com> <3b1405cd-6c7f-4883-95fb-151cab223a68@cogentembedded.com> <25ff0841-545b-433a-8e88-6e463ea718e7@cogentembedded.com> <237bee8b-a7cf-4c14-9946-8bf72dbddde5@cogentembedded.com> <5b8bcf37-5cd0-4c32-b0ba-3386142b7795@cogentembedded.com> Content-Language: en-US, ru-RU In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > Unfortunately, your argumentation is very _academic_. There is _no_practical_reason_, not to > forward the traffic to the SW bridge via the HW bridge, even if only one link is currently up. The very practical reason not to forward packet to SW when it can be handled in HW is - reduce SW load. SW cores have no chance to handle the load if you forward everything to SW at the channel speed. The very thing I was trying to achieve when working on this offload support was - detect the case when a frame can be processed correctly in HW, and let it process it in HW, without notifying SW. And send frame to SW if and only if it is not possible to provide correct processing without that. But this does not directly affect the case being discussed. When there is only one port with enabled HW forwarding, there is no effect of keeping HW forwarding enabled, because the allowed destination mask computed nearby does not contain any destinations. Forwarding to CPU port was never handled via L2 forwarding (*), because L2 forwarding on rswitch requires explicit adding any possible destination MAC to the L2 table - which is problematic for CPU port, in generic case your software bridge device can be a part of a higher level construct, and you will have hard times to dynamically catch and process any changes in the list of possible destination MACs for the CPU port. For exact this reason, I implemented forwarding to SW port using "port based" thing, that is actually a fallback that rswitch uses when L3/L2 forwarding fails due to no table match. (*) when virtual ports come into scope, a case for L2 forwarding to CPU port appears. But still, "default" forwarding to SW is never handled as L2 forwarding. Nikita