All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <razor@blackwall.org>
To: David Ahern <dsahern@kernel.org>, netdev@vger.kernel.org
Cc: roopa@nvidia.com, idosch@idosch.org, kuba@kernel.org,
	davem@davemloft.net, bridge@lists.linux-foundation.org
Subject: Re: [PATCH net-next v3 0/8] net: bridge: add flush filtering support
Date: Wed, 13 Apr 2022 10:27:22 +0300	[thread overview]
Message-ID: <b9059a6e-353d-dea0-0d55-27829c8f51ae@blackwall.org> (raw)
In-Reply-To: <c418e95e-440e-0502-58f2-63179f370a98@kernel.org>

On 13/04/2022 05:04, David Ahern wrote:
> On 4/12/22 7:22 AM, Nikolay Aleksandrov wrote:
>> Hi,
>> This patch-set adds support to specify filtering conditions for a bulk
>> delete (flush) operation. This version uses a new nlmsghdr delete flag
>> called NLM_F_BULK in combination with a new ndo_fdb_del_bulk op which is
>> used to signal that the driver supports bulk deletes (that avoids
>> pushing common mac address checks to ndo_fdb_del implementations and
>> also has a different prototype and parsed attribute expectations, more
>> info in patch 03). The new delete flag can be used for any RTM_DEL*
>> type, implementations just need to be careful with older kernels which
>> are doing non-strict attribute parses. Here I use the fact that mac
> 
> overall it looks fine to me. The rollout of BULK delete for other
> commands will be slow so we need a way to reject the BULK flag if the
> handler does not support it. One thought is to add another flag to
> rtnl_link_flags (e.g., RTNL_FLAG_BULK_DEL_SUPPORTED) and pass that flag
> in for handlers that handle bulk delete and reject it for others in core
> rtnetlink code.

Good point, it will be nice to error out with something meaningful if
bulk delete isn't supported. I'll look into it.

Thanks,
 Nik


WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Aleksandrov <razor@blackwall.org>
To: David Ahern <dsahern@kernel.org>, netdev@vger.kernel.org
Cc: idosch@idosch.org, bridge@lists.linux-foundation.org,
	davem@davemloft.net, kuba@kernel.org, roopa@nvidia.com
Subject: Re: [Bridge] [PATCH net-next v3 0/8] net: bridge: add flush filtering support
Date: Wed, 13 Apr 2022 10:27:22 +0300	[thread overview]
Message-ID: <b9059a6e-353d-dea0-0d55-27829c8f51ae@blackwall.org> (raw)
In-Reply-To: <c418e95e-440e-0502-58f2-63179f370a98@kernel.org>

On 13/04/2022 05:04, David Ahern wrote:
> On 4/12/22 7:22 AM, Nikolay Aleksandrov wrote:
>> Hi,
>> This patch-set adds support to specify filtering conditions for a bulk
>> delete (flush) operation. This version uses a new nlmsghdr delete flag
>> called NLM_F_BULK in combination with a new ndo_fdb_del_bulk op which is
>> used to signal that the driver supports bulk deletes (that avoids
>> pushing common mac address checks to ndo_fdb_del implementations and
>> also has a different prototype and parsed attribute expectations, more
>> info in patch 03). The new delete flag can be used for any RTM_DEL*
>> type, implementations just need to be careful with older kernels which
>> are doing non-strict attribute parses. Here I use the fact that mac
> 
> overall it looks fine to me. The rollout of BULK delete for other
> commands will be slow so we need a way to reject the BULK flag if the
> handler does not support it. One thought is to add another flag to
> rtnl_link_flags (e.g., RTNL_FLAG_BULK_DEL_SUPPORTED) and pass that flag
> in for handlers that handle bulk delete and reject it for others in core
> rtnetlink code.

Good point, it will be nice to error out with something meaningful if
bulk delete isn't supported. I'll look into it.

Thanks,
 Nik


  reply	other threads:[~2022-04-13  7:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-12 13:22 [PATCH net-next v3 0/8] net: bridge: add flush filtering support Nikolay Aleksandrov
2022-04-12 13:22 ` [Bridge] " Nikolay Aleksandrov
2022-04-12 13:22 ` [PATCH net-next v3 1/8] net: netlink: add NLM_F_BULK delete request modifier Nikolay Aleksandrov
2022-04-12 13:22   ` [Bridge] " Nikolay Aleksandrov
2022-04-12 13:22 ` [PATCH net-next v3 2/8] net: add ndo_fdb_del_bulk Nikolay Aleksandrov
2022-04-12 13:22   ` [Bridge] " Nikolay Aleksandrov
2022-04-12 13:22 ` [PATCH net-next v3 3/8] net: rtnetlink: add NLM_F_BULK support to rtnl_fdb_del Nikolay Aleksandrov
2022-04-12 13:22   ` [Bridge] " Nikolay Aleksandrov
2022-04-12 13:22 ` [PATCH net-next v3 4/8] net: bridge: fdb: add ndo_fdb_del_bulk Nikolay Aleksandrov
2022-04-12 13:22   ` [Bridge] " Nikolay Aleksandrov
2022-04-12 22:44   ` Nikolay Aleksandrov
2022-04-12 22:44     ` [Bridge] " Nikolay Aleksandrov
2022-04-12 13:22 ` [PATCH net-next v3 5/8] net: bridge: fdb: add support for fine-grained flushing Nikolay Aleksandrov
2022-04-12 13:22   ` [Bridge] " Nikolay Aleksandrov
2022-04-12 13:22 ` [PATCH net-next v3 6/8] net: rtnetlink: add ndm flags and state mask attributes Nikolay Aleksandrov
2022-04-12 13:22   ` [Bridge] " Nikolay Aleksandrov
2022-04-12 13:22 ` [PATCH net-next v3 7/8] net: bridge: fdb: add support for flush filtering based on ndm flags and state Nikolay Aleksandrov
2022-04-12 13:22   ` [Bridge] " Nikolay Aleksandrov
2022-04-12 13:32   ` Nikolay Aleksandrov
2022-04-12 13:32     ` [Bridge] " Nikolay Aleksandrov
2022-04-12 13:22 ` [PATCH net-next v3 8/8] net: bridge: fdb: add support for flush filtering based on ifindex and vlan Nikolay Aleksandrov
2022-04-12 13:22   ` [Bridge] " Nikolay Aleksandrov
2022-04-12 22:50 ` [PATCH net-next v3 0/8] net: bridge: add flush filtering support Nikolay Aleksandrov
2022-04-12 22:50   ` [Bridge] " Nikolay Aleksandrov
2022-04-13  2:04 ` David Ahern
2022-04-13  2:04   ` [Bridge] " David Ahern
2022-04-13  7:27   ` Nikolay Aleksandrov [this message]
2022-04-13  7:27     ` Nikolay Aleksandrov

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=b9059a6e-353d-dea0-0d55-27829c8f51ae@blackwall.org \
    --to=razor@blackwall.org \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=idosch@idosch.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.