From: Vlad Yasevich <vyasevic@redhat.com>
To: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Cc: netdev@vger.kernel.org, shemminger@vyatta.com,
bridge@lists.linux-foundation.org, davem@davemloft.net,
mst@redhat.com
Subject: Re: [Bridge] [PATCH net-next V6 02/14] bridge: Add vlan filtering infrastructure
Date: Mon, 21 Jan 2013 01:56:12 -0000 [thread overview]
Message-ID: <50FCA038.1010307@redhat.com> (raw)
In-Reply-To: <20130120233851.3f589fa4.shmulik.ladkani@gmail.com>
On 01/20/2013 04:38 PM, Shmulik Ladkani wrote:
> Hi Vlad,
>
> On Wed, 16 Jan 2013 13:17:57 -0500 Vlad Yasevich <vyasevic@redhat.com> wrote:
>> @@ -156,6 +183,7 @@ struct net_bridge_port
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> struct netpoll *np;
>> #endif
>> + struct net_port_vlans vlan_info;
>
> (here and at 'struct net_bridge' as well)
>
> Not sure what the policy is; Isn't it preferred to enclose the new
> fields under CONFIG_BRIDGE_VLAN_FILTERING?
Good catch. Missed this one.
>
>> +static inline struct net_bridge *vlans_to_bridge(struct net_port_vlans *vlans)
>> +{
>> + struct net_bridge *br;
>> +
>> + if (!vlans->port_idx)
>> + br = container_of((vlans), struct net_bridge, vlan_info);
>> + else
>> + br = vlans_to_port(vlans)->br;
>> +
>> + return br;
>> +}
>
> Guess it would simplify things if the bridge "master port" had an 'nbp'
> representation of its own ;-)
Yes that would simplify things for this case, but it will also add a lot
of state that's not necessary. I considered doing this, but the master
device doesn't really act as port in on things, just some.
>
>> +extern struct net_bridge_vlan *br_vlan_find(struct net_bridge *br, u16 vid);
>
> Seems 'br_vlan_find' can be declared static within br_vlan.c.
Will check.
>
>> +extern void br_vlan_flush(struct net_bridge *br);
>
> According to your preference, consider s/br_vlan_flush/br_vlans_flush/
> since it better suggest acting on all bridge's vlans.
>
>> +extern void nbp_vlan_flush(struct net_port_vlans *vlans);
>
> According to your preference, consider s/nbp_vlan_flush/nbp_vlans_flush/
> since it better suggest acting on all port's vlans.
>
>> +void br_vlan_flush(struct net_bridge *br)
>> +{
>> + struct net_bridge_vlan *vlan;
>> + struct hlist_node *node;
>> + struct hlist_node *tmp;
>> + int i;
>> +
>> + nbp_vlan_flush(&br->vlan_info);
>> +
>> + /* Make sure that there are no vlans left in the bridge after
>> + * all the ports have been removed.
>> + */
>
> Improper indent.
will fix
>
>> + for (i = 0; i < BR_VID_HASH_SIZE; i++) {
>> + hlist_for_each_entry_safe(vlan, node, tmp,
>> + &br->vlan_hlist[i], hlist) {
>> + br_vlan_del(vlan);
>
> Can there be any vlans left at that point? Shouldn't del_nbp() on all
> ports take care of that?
I think this function might have been a leftover from prior series when
bridge didn't have its vlan list. With the new series, I don't this it
is needed. I'll double-check.
Thanks
-vlad
> Also, if there _were_ any vlans left (whose bitmap isn't cleared),
> 'br_vlan_del' won't do a thing.
> Am I missing something?
>
> Regards,
> Shmulik
>
next prev parent reply other threads:[~2013-01-21 1:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-16 18:18 [Bridge] [PATCH net-next V6 00/14] Add basic VLAN support to bridges Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 01/14] vlan: wrap hw-acceleration calls in separate functions Vlad Yasevich
2013-01-16 22:03 ` Michał Mirosław
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 02/14] bridge: Add vlan filtering infrastructure Vlad Yasevich
2013-01-18 1:57 ` Michał Mirosław
2013-01-20 17:59 ` Vlad Yasevich
2013-01-20 19:39 ` Stephen Hemminger
2013-01-21 1:51 ` Vlad Yasevich
2013-01-21 11:45 ` Shmulik Ladkani
2013-01-22 14:31 ` Vlad Yasevich
2013-01-22 15:55 ` Shmulik Ladkani
2013-01-22 16:27 ` Vlad Yasevich
2013-01-20 21:39 ` Shmulik Ladkani
2013-01-21 1:56 ` Vlad Yasevich [this message]
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 03/14] bridge: Validate that vlan is permitted on ingress Vlad Yasevich
2013-01-20 22:27 ` Shmulik Ladkani
2013-01-21 1:58 ` Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 04/14] bridge: Verify that a vlan is allowed to egress on give port Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 05/14] bridge: Cache vlan in the cb for faster egress lookup Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 06/14] bridge: Add netlink interface to configure vlans on bridge ports Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 07/14] bridge: Add the ability to configure pvid Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 08/14] bridge: Implement vlan ingress/egress policy Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 09/14] bridge: API to configure egress policy Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 10/14] bridge: Add vlan to unicast fdb entries Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 11/14] bridge: Add vlan id to multicast groups Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 12/14] bridge: Add vlan support to static neighbors Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 13/14] bridge: Add vlan support for local fdb entries Vlad Yasevich
2013-01-16 18:18 ` [Bridge] [PATCH net-next V6 14/14] bridge: Dump vlan information from a bridge port Vlad Yasevich
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=50FCA038.1010307@redhat.com \
--to=vyasevic@redhat.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
--cc=shmulik.ladkani@gmail.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.