From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
To: Ido Schimmel <idosch@mellanox.com>
Cc: bridge@lists.linux-foundation.org,
Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
netdev@vger.kernel.org, Nikolay Aleksandrov <razor@blackwall.org>,
shm@cumulusnetworks.com, davem@davemloft.net, sfeldma@gmail.com,
roopa@cumulusnetworks.com
Subject: Re: [Bridge] [PATCH net-next 4/4] bridge: vlan: combine (br|nbp)_vlan_flush into one
Date: Mon, 12 Oct 2015 15:49:49 -0400 [thread overview]
Message-ID: <20151012194949.GA2325@ketchup.lan> (raw)
In-Reply-To: <20151012182713.GA17416@colbert.mtl.com>
On Oct. Monday 12 (42) 09:27 PM, Ido Schimmel wrote:
> Mon, Oct 12, 2015 at 09:15:39PM IDT, vivien.didelot@savoirfairelinux.com wrote:
> >Hi,
> >
> >On Oct. Monday 12 (42) 08:51 PM, Ido Schimmel wrote:
> >> Mon, Oct 12, 2015 at 02:41:09PM IDT, razor@blackwall.org wrote:
> >> >From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> >> >
> >> >As Ido Schimmel pointed out the vlan_vid_del() loop in nbp_vlan_flush is
> >> >unnecessary (and is actually a remnant of the old vlan code) so we can
> >> >remove it and combine both br/nbp vlan_flush functions into one.
> >> Just a small note to Scott and Vivien:
> >>
> >> One of the side effects of Nik's recent patchsets is that when VLANs are
> >> flushed on a port the deletion is propagated to the driver via
> >> switchdev ops, as __vlan_vid_del is called.
> >>
> >> Therefore there is no need to do internal bookkeeping and remove VLANs
> >> yourself when port is removed from bridge.
> >
> >I was thinking about caching VLAN entries in the mv88e6xxx driver to
> >improve look up on VLAN and FDB operations, but it's a bit prematurate.
> >
> >But when VLAN are flushed, we still need to remove them from the
> >hardware table, right?
> Hi,
>
> Not sure I'm following. You'll simply get a SWITCHDEV_OBJ_ID_PORT_VLAN
> (del) for each VLAN configured on the port you just removed from the bridge.
> I guess you remove them from your hardware table in the implementation
> of these ops?
Yes we do remove VLAN entries from the hardware table when
switchdev_port_obj_del(SWITCHDEV_OBJ_ID_PORT_VLAN) is called.
I may have misunderstood your previous note, I thought we were talking
about implementing the flush operation in switchdev drivers.
> >
> >Flushing is interesting though, most hardware have flush operations and
> >it would be interesting to have switchdev fdb_flush and vlan_flush ops.
Thanks,
-v
WARNING: multiple messages have this Message-ID (diff)
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
To: Ido Schimmel <idosch@mellanox.com>
Cc: Nikolay Aleksandrov <razor@blackwall.org>,
sfeldma@gmail.com, netdev@vger.kernel.org,
shm@cumulusnetworks.com, roopa@cumulusnetworks.com,
stephen@networkplumber.org, bridge@lists.linux-foundation.org,
davem@davemloft.net,
Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Subject: Re: [PATCH net-next 4/4] bridge: vlan: combine (br|nbp)_vlan_flush into one
Date: Mon, 12 Oct 2015 15:49:49 -0400 [thread overview]
Message-ID: <20151012194949.GA2325@ketchup.lan> (raw)
In-Reply-To: <20151012182713.GA17416@colbert.mtl.com>
On Oct. Monday 12 (42) 09:27 PM, Ido Schimmel wrote:
> Mon, Oct 12, 2015 at 09:15:39PM IDT, vivien.didelot@savoirfairelinux.com wrote:
> >Hi,
> >
> >On Oct. Monday 12 (42) 08:51 PM, Ido Schimmel wrote:
> >> Mon, Oct 12, 2015 at 02:41:09PM IDT, razor@blackwall.org wrote:
> >> >From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> >> >
> >> >As Ido Schimmel pointed out the vlan_vid_del() loop in nbp_vlan_flush is
> >> >unnecessary (and is actually a remnant of the old vlan code) so we can
> >> >remove it and combine both br/nbp vlan_flush functions into one.
> >> Just a small note to Scott and Vivien:
> >>
> >> One of the side effects of Nik's recent patchsets is that when VLANs are
> >> flushed on a port the deletion is propagated to the driver via
> >> switchdev ops, as __vlan_vid_del is called.
> >>
> >> Therefore there is no need to do internal bookkeeping and remove VLANs
> >> yourself when port is removed from bridge.
> >
> >I was thinking about caching VLAN entries in the mv88e6xxx driver to
> >improve look up on VLAN and FDB operations, but it's a bit prematurate.
> >
> >But when VLAN are flushed, we still need to remove them from the
> >hardware table, right?
> Hi,
>
> Not sure I'm following. You'll simply get a SWITCHDEV_OBJ_ID_PORT_VLAN
> (del) for each VLAN configured on the port you just removed from the bridge.
> I guess you remove them from your hardware table in the implementation
> of these ops?
Yes we do remove VLAN entries from the hardware table when
switchdev_port_obj_del(SWITCHDEV_OBJ_ID_PORT_VLAN) is called.
I may have misunderstood your previous note, I thought we were talking
about implementing the flush operation in switchdev drivers.
> >
> >Flushing is interesting though, most hardware have flush operations and
> >it would be interesting to have switchdev fdb_flush and vlan_flush ops.
Thanks,
-v
next prev parent reply other threads:[~2015-10-12 19:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-12 11:41 [Bridge] [PATCH net-next 0/4] bridge: vlan: cleanups & fixes (part 3) Nikolay Aleksandrov
2015-10-12 11:41 ` Nikolay Aleksandrov
2015-10-12 11:41 ` [Bridge] [PATCH net-next 1/4] bridge: vlan: use proper rcu for the vlgrp member Nikolay Aleksandrov
2015-10-12 11:41 ` Nikolay Aleksandrov
2015-10-12 17:29 ` [Bridge] " Ido Schimmel
2015-10-12 17:29 ` Ido Schimmel
2015-10-12 11:41 ` [Bridge] [PATCH net-next 2/4] bridge: vlan: use rcu for vlan_list traversal in br_fill_ifinfo Nikolay Aleksandrov
2015-10-12 11:41 ` Nikolay Aleksandrov
2015-10-12 11:41 ` [Bridge] [PATCH net-next 3/4] bridge: vlan: break vlan_flush in two phases to keep old order Nikolay Aleksandrov
2015-10-12 11:41 ` Nikolay Aleksandrov
2015-10-12 17:39 ` [Bridge] " Ido Schimmel
2015-10-12 17:39 ` Ido Schimmel
2015-10-12 17:55 ` [Bridge] " Nikolay Aleksandrov
2015-10-12 17:55 ` Nikolay Aleksandrov
2015-10-12 18:15 ` [Bridge] " Ido Schimmel
2015-10-12 18:15 ` Ido Schimmel
2015-10-12 18:16 ` [Bridge] " Nikolay Aleksandrov
2015-10-12 18:16 ` Nikolay Aleksandrov
2015-10-12 11:41 ` [Bridge] [PATCH net-next 4/4] bridge: vlan: combine (br|nbp)_vlan_flush into one Nikolay Aleksandrov
2015-10-12 11:41 ` Nikolay Aleksandrov
2015-10-12 17:51 ` [Bridge] " Ido Schimmel
2015-10-12 17:51 ` Ido Schimmel
2015-10-12 18:15 ` [Bridge] " Vivien Didelot
2015-10-12 18:15 ` Vivien Didelot
2015-10-12 18:27 ` [Bridge] " Ido Schimmel
2015-10-12 18:27 ` Ido Schimmel
2015-10-12 19:49 ` Vivien Didelot [this message]
2015-10-12 19:49 ` Vivien Didelot
2015-10-13 6:41 ` [Bridge] " Scott Feldman
2015-10-13 6:41 ` Scott Feldman
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=20151012194949.GA2325@ketchup.lan \
--to=vivien.didelot@savoirfairelinux.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=idosch@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=razor@blackwall.org \
--cc=roopa@cumulusnetworks.com \
--cc=sfeldma@gmail.com \
--cc=shm@cumulusnetworks.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.