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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E2D3C38A30 for ; Sun, 19 Apr 2020 16:42:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2AF6721D94 for ; Sun, 19 Apr 2020 16:42:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="zkki5Y4g" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726719AbgDSQmz (ORCPT ); Sun, 19 Apr 2020 12:42:55 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:48554 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725793AbgDSQmy (ORCPT ); Sun, 19 Apr 2020 12:42:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: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=iFsgbsnFgsbhPnlwLkM/14implnwlgFFSCTSxq+tcOw=; b=zkki5Y4g8r/noSSk8K8IMG45Dk ABEzJAmZy53zZSiAiqq06tQWxQUDcE9CUBbSbL9pfMZStX/PZRiXzT39drwbUYMd2NfyC1enPFhHj vESZVSEWGOnAyt8s9fgFKY5i0ORHuMm+V2LShbCvmICvbmgdmSV0QGvM8GHbssEJkxps=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1jQD1v-003ewJ-1B; Sun, 19 Apr 2020 18:42:51 +0200 Date: Sun, 19 Apr 2020 18:42:51 +0200 From: Andrew Lunn To: DENG Qingfang Cc: netdev@vger.kernel.org, Vivien Didelot , Florian Fainelli , Roopa Prabhu , bridge@lists.linux-foundation.org, Nikolay Aleksandrov , Jakub Kicinski , "David S . Miller" , =?iso-8859-1?Q?Ren=E9?= van Dorst Subject: Re: [RFC PATCH net-next] net: bridge: fix client roaming from DSA user port Message-ID: <20200419164251.GM836632@lunn.ch> References: <20200419161946.19984-1-dqfext@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200419161946.19984-1-dqfext@gmail.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Apr 20, 2020 at 12:19:46AM +0800, DENG Qingfang wrote: > When a client roams from a DSA user port to a soft-bridged port (such as WiFi > interface), the left-over MAC entry in the switch HW is not deleted, causing > inconsistency between Linux fdb and the switch MAC table. As a result, the > client cannot talk to other hosts which are on that DSA user port until the > MAC entry expires. > > Solve this by notifying switchdev fdb to delete the leftover entry when an > entry is updated. Remove the added_by_user check in DSA > > Signed-off-by: DENG Qingfang > --- > I tried this on mt7530 and mv88e6xxx, but only mt7530 works. > In previous discussion[1], Andrew Lunn said "try playing with auto learning > for the CPU port" but it didn't work on mv88e6xxx either Hi Deng We should probably first define how we expect moving MAC to work. Then we can make any core fixes, and driver fixes. For DSA, we have assumed that the software bridge and the hardware bridge are independent, each performs its own learning. Only static entries are kept in sync. How should this separate learning work for a MAC address which moves? Andrew