From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (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 41CFB3033C4 for ; Fri, 6 Feb 2026 16:10:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770394229; cv=none; b=errNQypaQYxNx65CBhKAteYU4UXKRWpgZT2pz3z6iVjW5W655apxI2STpLXzocU02i/356S3cZv0LXraX3cWGcXVjmulZoZyrH0rBQrONVNAnthCUy/BD2btRX+JmIrOiuMlVnzkJCoePUz7/7So4II8jsYsKpsJ2fBadvVv32M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770394229; c=relaxed/simple; bh=wTO4w0jGGKNWWyVRPeBBuZHYWyGfWSj0HikzN1o1OD4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uDC16G1X+5BwvB2/LPg7Q2Gc5i9A9h+0JWTdO3a3t3h5VF24iEHz6BrBHEqEy3vM/VU987yQoTGm35oIjWn6gKbpNuJkk/ZdKTqamg8TL2CsaMqwHHYkJ0GAOBX9lI0+o9AOzYeEo/16SfhIlvir15feh5iCyNMR6OeX733MMV0= 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=JjCatdgx; arc=none smtp.client-ip=209.85.221.49 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="JjCatdgx" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-436309f1ad7so177224f8f.3 for ; Fri, 06 Feb 2026 08:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cogentembedded-com.20230601.gappssmtp.com; s=20230601; t=1770394228; x=1770999028; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ctwbS8EWesRYrg5+xa1qLeZZuWqYJMD4QKuaVTduh68=; b=JjCatdgxWSXHY7iBex4yusKaYTlB83pDJzowjSrhludaQ+AH94JnpcRNRgRxtiPMPC 69DaRDYAkyO3LycwxJNsGpGvId2zb6m+PkC0ROGx7sZH2GqF7Erb6TrnVUDtZfyVQH5s eAb/42+TEXmW8iPx09cO16IyY3GaBpLuswcTpwhEIkmjanWO9lOw3yCKrNz3Xf6mOKlV 2TmRxNYZ9UvmkJnffcQH+fkpLLWQLMQOkv4xnV5Y5SzCbxjhQjd+/WRhgnF8/bwPNkTB JvSEthfYTz4Ac3+WfYNWeTaMwQDdoVQSn9vXkWktlWfg5kCY2+urcNrxFjEgQgEmj3Eo nTfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770394228; x=1770999028; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ctwbS8EWesRYrg5+xa1qLeZZuWqYJMD4QKuaVTduh68=; b=NbeFrpW6UMpx8vVLTtV3XnBABxsKL7nLoGm8jdlPL1xilQG+8KSYzqLBVfRJIihADv 97hCujEsBy4IaWjAL/T5IM/S4PtKR+fNCVe0Dpf+LjRdQ8zlv6/o2itZ28Lq9t4gg4ad TBwp8KYLWNhwdCcWzES1br02W5Q5za2ob1xWJrVfkPO4DFyw6iSACapduxmSngvZUWdX B4bk4EQ90BPK1mynSubHkkwNCnGnZQu1munYplQfUqVuEG0f5CfKHsBB4tf+RAtYhrcX rfm6X4O3SGE/Et0nTR2MInYXWEfdHOvtwKMAorv4ZjtsnGnwrGF6srBi56TjaohPN4GR 5QGg== X-Forwarded-Encrypted: i=1; AJvYcCWav/FNJA3Bt87tHprUK+CjPhWHdODbJb/snpL9r1CSggh6SDvHKDeUlpk3pGoZmHolgnxS2ZgCMBvVxl4=@vger.kernel.org X-Gm-Message-State: AOJu0YzqwMK7Bmvj8Z/OlW4gy+JW8zCXlYEgrcverRpaciG2QVIDIFsx CZsTKGMaOmUn2aNF9+p2/0kjJEvsAwNnrMeCgr6fTVbe8vSEz/g5HV6ABtoDsx3JGsU= X-Gm-Gg: AZuq6aK/cgpZZx4hBu22/jAKVOzmsfkF/W34QIKfrIEhVKZVqNg+zplkDsT1UhBZXg+ LZG/l+yms/a1A278M+IjlHZNbuS/oRjGiVibWyPN9WTDnW+Oboc71gChLoSE6eb4N2uH5PJ8X1r AdD4/0fqw9XoiM5VL7peswSS7CRcpSDZZExjKMui3LSz8lcOoXkAItcyBm+9XX1Rz1+9Ntb/+md sOavDV59+7IwmJA0NmVWJMA2rivsIApI9v4mI5FDZMH74YqhkEXsc7CXDN21g16s8cZdwmYIKKR sMWP2T7809quVorEfnGf9qcSCiy66zby9CozavviPU9L+49d2wQah5pEX8RtmMvg7P1PzXTGIuH sTYgj/TJZhsJX3VTYdZJ3D/MoNzIiH26g84Qb8dc0IrQDrmx8X4tzCtDpqIRHjrr8Aau+olwAAh y+iTCS4b59Tr7NiLvd+57GG9hOsRQvcCNEmqdBK4krEqNnA+s= X-Received: by 2002:a05:600c:19c7:b0:45d:dc85:c009 with SMTP id 5b1f17b1804b1-483201e160dmr43791245e9.10.1770394227499; Fri, 06 Feb 2026 08:10:27 -0800 (PST) Received: from ?IPV6:2a02:810a:b98:a000::159a? ([2a02:810a:b98:a000::159a]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43629754c62sm6271284f8f.38.2026.02.06.08.10.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Feb 2026 08:10:27 -0800 (PST) Message-ID: Date: Fri, 6 Feb 2026 17:10:26 +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 Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine To: Andrew Lunn Cc: Michael Dege , Yoshihiro Shimoda , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , "netdev@vger.kernel.org" , "linux-renesas-soc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Christian Mardmoeller , Dennis Ostermann References: <25ff0841-545b-433a-8e88-6e463ea718e7@cogentembedded.com> <237bee8b-a7cf-4c14-9946-8bf72dbddde5@cogentembedded.com> <5b8bcf37-5cd0-4c32-b0ba-3386142b7795@cogentembedded.com> <1aa615e2-1297-40a9-b7c4-beb943996721@cogentembedded.com> <38e09d91-c514-4090-8e31-1709073b237a@lunn.ch> Content-Language: en-US, ru-RU From: Nikita Yushchenko In-Reply-To: <38e09d91-c514-4090-8e31-1709073b237a@lunn.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > > DSA switches handle the CPU port in a few different ways: > > * They do address learning, so learn what MAC addresses are in the > direction of the CPU from the traffic sent by the CPU. rswitch does not support hardware learning on CPU port. To make use of L2 forwarding to CPU port, one has to add destinations to MAC table manually. > * All frames with a destination MAC address not in the address > translation unit get sent to the CPU. This is sometimes implicit, > the CPU is included in the flood for unknown MAC addresses, or there > is an explicit bit to enable this. The software bridge will then > handle the frame. The reply, if there is one, should then trigger > address learning. rswitch does not do anything implicitly, each frame is processed by trying in order: - match it against "streams" in L3 table, - match it against destination addresses in L2 table, - match it against VLAN table (VLAN id only), - try port-based forwarding (i.e. common rule for anything coming from particular ingress port) At each of this level, it is possible to configure one or several destinations to forward frame to. Flooding can be implemented e.g. by configuring "port based" for each port to forward to all other ports, so if a frame is matched at earlier stages then it is processed per what is defined there, and if not then it is flooded. > * The switch driver taps into the events the software bridge issues as > it does address learning. This allows the switch to setup its > address translation tables to mirror the software switch. For rswitch there is no easy way to sync hardware-learned L2 entries to software. There are no notifications of hardware updates. Options are: - either periodically scan hardware table, or - disable hardware learning at all and send any unknown frames to software bridge, so it learns, and then handle notifications about that and manually update hardware table. The existing implementation does not try to sync sw and hw tables at all. > The overall result is that having just one switch port in the bridge > is no different to having multiple switch ports in the bridge. In my original driver, I enabled L2 forwarding only when at least two ports have been participating. I don't see rationale for doing differently on this hardware. But Renesas can have a different view on this. Nikita