[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53831FDD.4020902@mojatatu.com>
Date: Mon, 26 May 2014 07:05:01 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Ben Hutchings <ben@...adent.org.uk>
CC: davem@...emloft.net, netdev@...r.kernel.org,
stephen@...workplumber.org, vyasevic@...hat.com,
john.r.fastabend@...el.com, sfeldma@...ulusnetworks.com
Subject: Re: [net-next PATCH v2 1/1] bring netlink interface to par with brctl
show macs
On 05/25/14 22:35, Ben Hutchings wrote:
> On Sun, 2014-05-25 at 09:15 -0400, Jamal Hadi Salim wrote:
>> + if (dev == NULL) {
>> + pr_info("PF_BRIDGE: RTM_GETNEIGH with unknown ifindex\n");
>
> You left another debug message here.
>
>> + return -ENODEV;
>> }
>> + pr_info("PF_BRIDGE: RTM_GETNEIGH %s no dumper\n",
>> + dev->name);
>
> And here.
Those two just adhere to the coding style used in the rest of the fdb
code. I could remove them and send subsequent patches to remove
equivalent debugs in the rest of the code. To me they seem useful
although i have seen very strong views against them in the past.
>> + return -EINVAL;
>> + }
> [...]
>
> Why does this only call the device's own ndo_fdb_dump and not a
> bridge-port's bridge's ndo_fdb_dump or ndo_dflt_fdb_dump?
The target is a specific bridge not a bridge port. Having
said that, it is (probably) possible there are physical or virtual
bridge ports whose master is the targeted bridge that are sheltering
fdb entries we want to dump that are not in the bridge's fdb.
Macvlans or vmdq maybe? What did you have in mind?
cheers,
jamal
> Ben.
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists