public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joseph Huang <joseph.huang.2024@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>,
	Joseph Huang <Joseph.Huang@garmin.com>
Cc: netdev@vger.kernel.org, "Andrew Lunn" <andrew@lunn.ch>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Roopa Prabhu" <roopa@nvidia.com>,
	"Nikolay Aleksandrov" <razor@blackwall.org>,
	"Linus Lüssing" <linus.luessing@c0d3.blue>,
	linux-kernel@vger.kernel.org, bridge@lists.linux.dev
Subject: Re: [PATCH RFC net-next 07/10] net: dsa: mv88e6xxx: Track bridge mdb objects
Date: Thu, 4 Apr 2024 16:43:38 -0400	[thread overview]
Message-ID: <b5f79571-b4a8-4f21-8dc8-e1aa11056a5d@gmail.com> (raw)
In-Reply-To: <20240402122343.a7o5narxsctrkaoo@skbuf>

Hi Vladimir,

On 4/2/2024 8:23 AM, Vladimir Oltean wrote:
> Can you comment on the feasibility/infeasibility of Tobias' proposal of:
> "The bridge could just provide some MDB iterator to save us from having
> to cache all the configured groups."?
> https://lore.kernel.org/netdev/87sg31n04a.fsf@waldekranz.com/
> 
> What is done here will have to be scaled to many drivers - potentially
> all existing DSA ones, as far as I'm aware.
> 

I thought about implementing an MDB iterator as suggested by Tobias, but 
I'm a bit concerned about the coherence of these MDB objects. In theory, 
when the device driver is trying to act on an event, the source of the 
trigger may have changed its state in the bridge already. If, upon 
receiving an event in the device driver, we iterate over what the bridge 
has at that instant, the differences between the worlds as seen by the 
bridge and the device driver might lead to some unexpected results. 
However, if we cache the MDB objects in the device driver, at least the 
order in which the events took place will be coherent and at any give 
time the state of the MDB objects in the device driver can be guaranteed 
to be sane. This is also the approach the prestera device driver took.

Thanks,
Joseph

  reply	other threads:[~2024-04-04 20:43 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02  0:10 [PATCH RFC net-next 00/10] MC Flood disable and snooping Joseph Huang
2024-04-02  0:11 ` [PATCH RFC net-next 01/10] net: bridge: Flood Queries even when mc flood is disabled Joseph Huang
2024-04-02  0:11 ` [PATCH RFC net-next 02/10] net: bridge: Always multicast_flood Reports Joseph Huang
2024-04-03 15:52   ` Simon Horman
2024-04-02  0:11 ` [PATCH RFC net-next 03/10] net: bridge: Always flood local subnet mc packets Joseph Huang
2024-04-02  0:11 ` [PATCH RFC net-next 04/10] net: dsa: mv88e6xxx: Add all hosts mc addr to ATU Joseph Huang
2024-04-02 18:08   ` Vladimir Oltean
2024-04-02  0:11 ` [PATCH RFC net-next 05/10] net: dsa: Add support for PORT_MROUTER attribute Joseph Huang
2024-04-02  0:11 ` [PATCH RFC net-next 06/10] net: dsa: mv88e6xxx: Track soft bridge objects Joseph Huang
2024-04-02  0:11 ` [PATCH RFC net-next 07/10] net: dsa: mv88e6xxx: Track bridge mdb objects Joseph Huang
2024-04-02 12:23   ` Vladimir Oltean
2024-04-04 20:43     ` Joseph Huang [this message]
2024-04-05 11:07       ` Vladimir Oltean
2024-04-05 18:58         ` Joseph Huang
2024-04-29 22:07           ` Joseph Huang
2024-04-30  0:59             ` Vladimir Oltean
2024-04-30 16:27               ` Joseph Huang
2024-05-02 20:37                 ` Joseph Huang
2024-04-02  0:11 ` [PATCH RFC net-next 08/10] net: dsa: mv88e6xxx: Convert MAB to use bit flags Joseph Huang
2024-04-02  0:11 ` [PATCH RFC net-next 09/10] net: dsa: mv88e6xxx: Enable mc flood for mrouter port Joseph Huang
2024-04-03 15:49   ` Simon Horman
2024-04-02  0:11 ` [PATCH RFC net-next 10/10] net: dsa: mv88e6xxx: Offload " Joseph Huang
2024-04-02  9:28 ` [PATCH RFC net-next 00/10] MC Flood disable and snooping Nikolay Aleksandrov
2024-04-02 17:43   ` Vladimir Oltean
2024-04-02 18:50     ` Nikolay Aleksandrov
2024-04-02 20:46       ` Vladimir Oltean
2024-04-02 21:59         ` Nikolay Aleksandrov
2024-04-04 22:16           ` Joseph Huang
2024-04-05 10:20             ` Vladimir Oltean
2024-04-05 11:00               ` Nikolay Aleksandrov
2024-04-05 20:22                 ` Joseph Huang
2024-04-05 21:15                   ` Vladimir Oltean
2024-04-29 20:14                     ` Joseph Huang
2024-04-30  1:21                       ` Vladimir Oltean
2024-04-30 17:01                         ` Joseph Huang
2024-05-02 12:12                           ` Nikolay Aleksandrov
2025-02-26 20:20                             ` Linus Lüssing
2025-02-26 22:17                               ` Linus Lüssing
2024-04-02 12:43 ` Andrew Lunn
2024-04-04 21:35   ` Joseph Huang
2024-04-04 22:11     ` Andrew Lunn
2024-04-04 22:40       ` Joseph Huang
2024-04-05 13:09         ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b5f79571-b4a8-4f21-8dc8-e1aa11056a5d@gmail.com \
    --to=joseph.huang.2024@gmail.com \
    --cc=Joseph.Huang@garmin.com \
    --cc=andrew@lunn.ch \
    --cc=bridge@lists.linux.dev \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linus.luessing@c0d3.blue \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.org \
    --cc=roopa@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox