netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Roopa Prabhu <roopa@nvidia.com>
Cc: Nikolay Aleksandrov <razor@blackwall.org>,
	netdev@vger.kernel.org, idosch@idosch.org, davem@davemloft.net,
	bridge@lists.linux-foundation.org
Subject: Re: [PATCH net-next v2 0/8] net: bridge: add flush filtering support
Date: Mon, 11 Apr 2022 12:49:10 -0700	[thread overview]
Message-ID: <20220411124910.772dc7a0@kernel.org> (raw)
In-Reply-To: <ca093c4f-d99c-d885-16cb-240b0ce4d8d8@nvidia.com>

On Mon, 11 Apr 2022 12:22:24 -0700 Roopa Prabhu wrote:
> >> I thought about that option, but I didn't like overloading delneigh like that.
> >> del currently requires a mac address and we need to either signal the device supports> a null mac, or we should push that verification to ndo_fdb_del users. Also we'll have  
> > that's the only thing, overloading delneigh with a flush-behaviour (multi-del or whatever)
> > would require to push the mac check to ndo_fdb_del implementers
> >
> > I don't mind going that road if others agree that we should do it through delneigh
> > + a bit/option to signal flush, instead of a new rtm type.
> >  
> >> attributes which are flush-specific and will work only when flushing as opposed to when
> >> deleting a specific mac, so handling them in the different cases can become a pain.  
> > scratch the specific attributes, those can be adapted for both cases
> >  
> >> MDBs will need DELMDB to be modified in a similar way.
> >>
> >> IMO a separate flush op is cleaner, but I don't have a strong preference.
> >> This can very easily be adapted to delneigh with just a bit more mechanical changes
> >> if the mac check is pushed to the ndo implementers.
> >>
> >> FLUSHNEIGH can easily work for neighs, just need another address family rtnl_register
> >> that implements it, the new ndo is just for PF_BRIDGE. :)  
> 
> all great points. My only reason to explore RTM_DELNEIGH is to see if we 
> can find a recipe to support similar bulk deletes of other objects 
> handled via rtm msgs in the future. Plus, it allows you to maintain 
> symmetry between flush requests and object delete notification msg types.
> 
> Lets see if there are other opinions.

I'd vote for reusing RTM_DELNEIGH, but that's purely based on
intuition, I don't know this code. I'd also lean towards core
creating struct net_bridge_fdb_flush_desc rather than piping
raw netlink attrs thru. Lastly feels like fdb ops should find 
a new home rather than ndos, but that's largely unrelated..

  reply	other threads:[~2022-04-11 19:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11 17:29 [PATCH net-next v2 0/8] net: bridge: add flush filtering support Nikolay Aleksandrov
2022-04-11 17:29 ` [PATCH net-next v2 1/8] net: rtnetlink: add RTM_FLUSHNEIGH Nikolay Aleksandrov
2022-04-11 22:57   ` David Ahern
2022-04-11 17:29 ` [PATCH net-next v2 2/8] net: add ndo_fdb_flush op Nikolay Aleksandrov
2022-04-11 17:29 ` [PATCH net-next v2 3/8] net: bridge: fdb: " Nikolay Aleksandrov
2022-04-11 17:29 ` [PATCH net-next v2 4/8] net: rtnetlink: register a generic rtnl_fdb_flush call Nikolay Aleksandrov
2022-04-11 17:29 ` [PATCH net-next v2 5/8] net: rtnetlink: add common flush attributes Nikolay Aleksandrov
2022-04-11 17:29 ` [PATCH net-next v2 6/8] net: bridge: fdb: add support for fine-grained flushing Nikolay Aleksandrov
2022-04-11 17:29 ` [PATCH net-next v2 7/8] net: bridge: fdb: add support for flush filtering based on ndm flags and state Nikolay Aleksandrov
2022-04-11 17:29 ` [PATCH net-next v2 8/8] net: bridge: fdb: add support for flush filtering based on ifindex and vlan Nikolay Aleksandrov
2022-04-11 17:42 ` [PATCH net-next v2 0/8] net: bridge: add flush filtering support Nikolay Aleksandrov
2022-04-11 18:08 ` Roopa Prabhu
2022-04-11 18:18   ` Nikolay Aleksandrov
2022-04-11 18:31     ` Nikolay Aleksandrov
2022-04-11 19:22       ` Roopa Prabhu
2022-04-11 19:49         ` Jakub Kicinski [this message]
2022-04-11 20:34           ` Nikolay Aleksandrov
2022-04-11 20:48             ` Jakub Kicinski
2022-04-11 21:17               ` Nikolay Aleksandrov
2022-04-11 21:35                 ` Jakub Kicinski
2022-04-11 23:03         ` David Ahern

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=20220411124910.772dc7a0@kernel.org \
    --to=kuba@kernel.org \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=idosch@idosch.org \
    --cc=netdev@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).