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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 A1CB2C3815B for ; Mon, 20 Apr 2020 13:31:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7E14220735 for ; Mon, 20 Apr 2020 13:31:17 +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="C7umDL1g" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727032AbgDTNbQ (ORCPT ); Mon, 20 Apr 2020 09:31:16 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:50686 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726582AbgDTNbQ (ORCPT ); Mon, 20 Apr 2020 09:31:16 -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=bTtcioAVktBgcUTfi+bs1vdsWqSYfUDLbtTIZdRCNz8=; b=C7umDL1g3lTk+Vwd6Q6R0TWE8u q7btrSM81MUhI7cA63GDWG6lBHEUvpaDoh5aKxalnyyfYBVroMKB0Jz+Xt1OLMaCdTaevIGn4k8GH wz8y9FMWVXo4VBUod7x34sn1aIm9rZklz06PbBUXAraOLvFVIah0Y70QY21SQ0Mv3x3Y=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1jQWW0-003pci-00; Mon, 20 Apr 2020 15:31:12 +0200 Date: Mon, 20 Apr 2020 15:31:11 +0200 From: Andrew Lunn To: DENG Qingfang Cc: netdev , 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: <20200420133111.GL785713@lunn.ch> References: <20200419161946.19984-1-dqfext@gmail.com> <20200419164251.GM836632@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > When a client moves from a hardware port (e.g. sw0p1) to a software port (wlan0) > or another hardware port that belongs to a different switch (sw1p1), > that MAC entry > in sw0's MAC table should be deleted, or replaced with the CPU port as > destination, > by DSA. Otherwise the client is unable to talk to other hosts on sw0 because sw0 > still thinks the client is on sw0p1. The MAC address needs to move, no argument there. But what are the mechanisms which cause this. Is learning sufficient, or does DSA need to take an active role? Forget about DSA for the moment. How does this work for two normal bridges? Is the flow of unicast packets sufficient? Does it requires a broadcast packet from the device after it moves? Andrew