From: Ido Schimmel <idosch@nvidia.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: petrm@nvidia.com, netdev@vger.kernel.org,
Nikolay Aleksandrov <razor@blackwall.org>,
bridge@lists.linux-foundation.org, edumazet@google.com,
mlxsw@nvidia.com, roopa@nvidia.com, kuba@kernel.org,
pabeni@redhat.com, davem@davemloft.net
Subject: Re: [Bridge] [RFC PATCH net-next 0/9] bridge: Add per-{Port, VLAN} neighbor suppression
Date: Wed, 19 Apr 2023 18:04:11 +0300 [thread overview]
Message-ID: <ZEAC6y6vIL37Gk2Q@shredder> (raw)
In-Reply-To: <20230419145124.5z47v2p62nbskqr2@skbuf>
On Wed, Apr 19, 2023 at 05:51:24PM +0300, Vladimir Oltean wrote:
> On Wed, Apr 19, 2023 at 04:59:54PM +0300, Ido Schimmel wrote:
> > On Wed, Apr 19, 2023 at 03:30:07PM +0300, Nikolay Aleksandrov wrote:
> > > For the set:
> > > Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
> >
> > Thanks! Will rebase, retest and submit v1
>
> Shouldn't the version numbers be independent of the RFC/PATCH
> designation (and thus this would be a v2)? I know I was extremely
> confused when I had to review a series by Colin Foster which jumped back
> and forth between PATCH v6, RFC v3, PATCH v7, etc.
Makes sense. Will mark it v2
WARNING: multiple messages have this Message-ID (diff)
From: Ido Schimmel <idosch@nvidia.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Nikolay Aleksandrov <razor@blackwall.org>,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@google.com, roopa@nvidia.com, petrm@nvidia.com,
mlxsw@nvidia.com
Subject: Re: [RFC PATCH net-next 0/9] bridge: Add per-{Port, VLAN} neighbor suppression
Date: Wed, 19 Apr 2023 18:04:11 +0300 [thread overview]
Message-ID: <ZEAC6y6vIL37Gk2Q@shredder> (raw)
In-Reply-To: <20230419145124.5z47v2p62nbskqr2@skbuf>
On Wed, Apr 19, 2023 at 05:51:24PM +0300, Vladimir Oltean wrote:
> On Wed, Apr 19, 2023 at 04:59:54PM +0300, Ido Schimmel wrote:
> > On Wed, Apr 19, 2023 at 03:30:07PM +0300, Nikolay Aleksandrov wrote:
> > > For the set:
> > > Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
> >
> > Thanks! Will rebase, retest and submit v1
>
> Shouldn't the version numbers be independent of the RFC/PATCH
> designation (and thus this would be a v2)? I know I was extremely
> confused when I had to review a series by Colin Foster which jumped back
> and forth between PATCH v6, RFC v3, PATCH v7, etc.
Makes sense. Will mark it v2
next prev parent reply other threads:[~2023-04-19 15:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 9:58 [Bridge] [RFC PATCH net-next 0/9] bridge: Add per-{Port, VLAN} neighbor suppression Ido Schimmel
2023-04-13 9:58 ` Ido Schimmel
2023-04-13 9:58 ` [Bridge] [RFC PATCH net-next 1/9] bridge: Reorder neighbor suppression check when flooding Ido Schimmel
2023-04-13 9:58 ` Ido Schimmel
2023-04-13 9:58 ` [Bridge] [RFC PATCH net-next 2/9] bridge: Pass VLAN ID to br_flood() Ido Schimmel
2023-04-13 9:58 ` Ido Schimmel
2023-04-13 9:58 ` [Bridge] [RFC PATCH net-next 3/9] bridge: Add internal flags for per-{Port, VLAN} neighbor suppression Ido Schimmel
2023-04-13 9:58 ` Ido Schimmel
2023-04-13 9:58 ` [Bridge] [RFC PATCH net-next 4/9] bridge: Take per-{Port, VLAN} neighbor suppression into account Ido Schimmel
2023-04-13 9:58 ` Ido Schimmel
2023-04-13 9:58 ` [Bridge] [RFC PATCH net-next 5/9] bridge: Encapsulate data path neighbor suppression logic Ido Schimmel
2023-04-13 9:58 ` Ido Schimmel
2023-04-13 9:58 ` [Bridge] [RFC PATCH net-next 6/9] bridge: Add per-{Port, VLAN} neighbor suppression data path support Ido Schimmel
2023-04-13 9:58 ` Ido Schimmel
2023-04-13 9:58 ` [Bridge] [RFC PATCH net-next 7/9] bridge: vlan: Allow setting VLAN neighbor suppression state Ido Schimmel
2023-04-13 9:58 ` Ido Schimmel
2023-04-13 9:58 ` [Bridge] [RFC PATCH net-next 8/9] bridge: Allow setting per-{Port, VLAN} " Ido Schimmel
2023-04-13 9:58 ` Ido Schimmel
2023-04-13 9:58 ` [Bridge] [RFC PATCH net-next 9/9] selftests: net: Add bridge neighbor suppression test Ido Schimmel
2023-04-13 9:58 ` Ido Schimmel
2023-04-19 12:30 ` [Bridge] [RFC PATCH net-next 0/9] bridge: Add per-{Port, VLAN} neighbor suppression Nikolay Aleksandrov
2023-04-19 12:30 ` Nikolay Aleksandrov
2023-04-19 13:59 ` [Bridge] " Ido Schimmel
2023-04-19 13:59 ` Ido Schimmel
2023-04-19 14:51 ` [Bridge] " Vladimir Oltean
2023-04-19 14:51 ` Vladimir Oltean
2023-04-19 15:04 ` Ido Schimmel [this message]
2023-04-19 15:04 ` Ido Schimmel
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=ZEAC6y6vIL37Gk2Q@shredder \
--to=idosch@nvidia.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.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 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.