From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.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 449A340B6EF for ; Wed, 12 Aug 2026 22:06:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786572394; cv=none; b=GxiSZ6DXQlseI9x/gttLZS4vNlYqZigYfDn9D58+gFwTfalkjwHJ1vo+dk0dcQbcw2RjfJ3AHTuf9Xc3+2y3YoHquM/tcJyCuSb+VPA0/vyaxxYI9yRwcYixf8h7SPxXYL4r+YUuL+Y+tlfnoaUKrxEDKNNg+HZviN/1JC1tY88= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786572394; c=relaxed/simple; bh=X7HIgkaLifJ7WbR8ThQH7BkEeoT/ljYKLvL7ifBOMv8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eyeFXboHzEJkb78HchhPz/8r8I2d+Kby/oRvsUIw+u9K7XYfxnfKpY1wchWXQpShqbYuhxT5GcN8RyFeHiuRM5GWfr9ADgo+70wgKT3XPwa2ypI024vQPq3tvEICO6mvouUlZAdjXn9lgEcahEiNWYhN/4Ist6gqH8NKJDqJBE8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=pRDBZx4O; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pRDBZx4O" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4954b3c5cbeso1305515e9.1 for ; Wed, 12 Aug 2026 15:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786572391; x=1787177191; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=gycqGURb6RcPySIhCipoHXd74YJ+idCVrbRkPRx4R0g=; b=pRDBZx4OVBCmbP0b854dJtDqNsxulP9UaPmxiFwY3dIOBfvNSqX+Y+Je5PW4L6aUoG rMXPv4hzM9dnaODUI4zk+UP145EAzO3onwtze0RWXRuatu4bP1ErXk9bEJqbAz4JrHkx iKRCWTVtR0T4voZiPvhVYrktlPA/MOhcbg4ByCpC7NIE4eECLMzWi80yZGgcmwaFXE5k iZpOORVTEctkhzm9puMK9d8QgarS/Ce4+ewRtLGMABhXJPcxkMHOhCP6m9bZFcJUFjRa TSXlTtNVZbTLkAOK2PPxhhjtZra6nWdM+91k13mRRDBAkiOIDNeAiGriB6QTKhlFPzou bNLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786572391; x=1787177191; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=gycqGURb6RcPySIhCipoHXd74YJ+idCVrbRkPRx4R0g=; b=ekgzdl0tGNL9bB9jHoP1QkeIjt5gXPnrKq0DTLu+nzrlB3lruxhLeLIAoQ4dZoYSI/ eo+I3CziSBQWErJ0O9Ot4LjdgoJc2L6tw4vGsQswuvj/be7MbFP63uvuHGN6SlTnHqCR pSPdadVVFmDE/cUZR4OxPxbJDd0FWISdU72rdqDC8XJ5byscHXu88U0a9gk+qJ+8LDhU gCq0z4hrzGi93ljGk286eCfVyqmH4LO8vZauDlzNmSlg6G1jts/8FCFi4Sh9/ZIyKLMQ fS6UAJVxLu4YOfjTwSyUY7l/K4rtTh+EzpwbcQZtJrvHoI6dTQ88H4138BHsRfgE1iD6 r3wA== X-Forwarded-Encrypted: i=1; AHgh+Ro7t/gAwNIZtDkPWMGaWPL0goa0oshmo0V0km4oI5maO93aNIZMe6mbmZnPaANFt+O0pttq7GVFbEIUZ8o=@vger.kernel.org X-Gm-Message-State: AOJu0YxpzMeFE1gMdHrHLi1XP1eWFMQrBQjPmxt19quGGXoQNuHRjNyp z/SRSTocaUYrV4UilB8ZqlFCUdeMLaoKpFPcPauM6BkuTM/nkQnSFVws X-Gm-Gg: AR+sD13yjPd90TbKe6Q3J0T7G8mtMEELaeIkPIbfyhD39cVD73B1b0BQ0VfsmWw8rq9 LKaUV0Gsk2/XFThcFYpn/l/4q7zfvuI1Mha3dBO5XtzLWfKSiUhxdBrkdpiaf/zUn+XkD1Rbu1J lC8/hInJpiDdm0/ProQBhVk1DJT+G7ygPJw+K5AVcvi6c3M0f+0cKGBwl/TFOR6j5aF8mqUOgDy 5ft5r7DN3A5M6+OhbVt6rsMNOpVMnrwqioI36NKOcal5MKTPKRczFaN7WJZAyaoMlXJe0IuUGdn BOzcB/yF+s0iCrF65SGGV2T9Ao6RZ13m4AN6N5yUXs5KtRsYJM6u1sZeRjA9VGvp8D1DxkRIYTX ZfMjKJc6jTQE6IBf4/Cs/eTvUXJyQAP79AgrFYrZlU1Eg9GFp5kTLZlRBLv8ryznJ8RVeiF0EtH 0+SFGNyEzsvp2QWGcPyU2eH90JDv39moi0KTKs5ehAF7PgXBn3 X-Received: by 2002:adf:e193:0:b0:47f:dfc1:6907 with SMTP id ffacd0b85a97d-4815a0005c0mr737263f8f.3.1786572391345; Wed, 12 Aug 2026 15:06:31 -0700 (PDT) Received: from skbuf ([86.127.220.200]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815a5af6b3sm835849f8f.20.2026.08.12.15.06.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 15:06:30 -0700 (PDT) Date: Thu, 13 Aug 2026 01:06:27 +0300 From: Vladimir Oltean To: Jonas Gorski Cc: Semih Baskan , florian.fainelli@broadcom.com, andrew@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, vladimir.oltean@nxp.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: dsa: b53: be VLAN unaware when not filtering Message-ID: <20260812220627.r6gesugv2q3s6x2o@skbuf> References: <20260805072641.402-1-strst.gs@gmail.com> <20260812205047.ojq2yyjtmoe5gjot@skbuf> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260812205047.ojq2yyjtmoe5gjot@skbuf> On Wed, Aug 12, 2026 at 11:50:47PM +0300, Vladimir Oltean wrote: > 1. This looks implementable with some complexity isolated within the b53 > driver: > - on any .port_fdb_add(), .port_fdb_del(), .port_mdb_add(), .port_mdb_del(), > compare the VID of the entry with the dev->vlan_enabled state. > - if VID != 0 and dev->vlan_enabled, or if VID == 0 and !dev->vlan_enabled, > commit the operation directly to the ARL, as is currently done > - if VID == 0 and !dev->vlan_enabled, or if VID != 0 and dev->vlan_enabled, > operate on a software list, allocating, deleting or modifying a > local representation of the ARL entry > - on vlan_filtering toggles from 0 to 1 or from 1 to 0, acquire > dev->arl_mutex and flush out all static and dynamic ARL entries > across the entire switch, commit the static ones from the software > list and clear the software list > - dev->vlan_enabled will probably need to be merged with > dev->vlan_filtering, since the vlan_enabled=1 vlan_filtering=0 case > is broken Actually this algorithm is too simplistic as I specified it. In this sequence: ip link add br0 type bridge vlan_filtering 0 && ip link set swp0 master br0 bridge fdb add swp0 00:01:02:03:04:05 master static ip link set br0 type bridge vlan_filtering 1 ip link set br0 type bridge vlan_filtering 0 # the 00:01:02:03:04:05 address would be lost here Furthermore, the ARL is limited in size (1024, 2048 or 4096 entries), and we could mistakenly end up queuing more than we can commit. I'm not yet sure what are reasonable amendments that would keep the complexity in check. Currently the most obvious would be to do a one-time allocation of dev->num_arl_bins * dev->num_arl_buckets, to always keep all entries in software, and only the active ones in hardware. But I need to think about this some more, as I'm aware OpenWrt typically doesn't operate with huge memory budgets. I'm not sure that avoiding local copies is possible, because the ARL entries don't come from a single source - we have bridge FDB, bridge MDB, ndo_dflt_fdb_add(), dev->uc, dev->mc, dev->dev_addr, sometimes replicated per VLAN, etc. They all only converge at driver level.