All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	stephen@networkplumber.org, vyasevic@redhat.com,
	john.r.fastabend@intel.com, sfeldma@cumulusnetworks.com
Subject: Re: [net-next PATCH v2 1/1] bring netlink interface to par with brctl show macs
Date: Mon, 26 May 2014 07:05:01 -0400	[thread overview]
Message-ID: <53831FDD.4020902@mojatatu.com> (raw)
In-Reply-To: <1401071747.17377.111.camel@deadeye.wl.decadent.org.uk>

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.
>

  reply	other threads:[~2014-05-26 11:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-25 13:15 [net-next PATCH v2 1/1] bring netlink interface to par with brctl show macs Jamal Hadi Salim
2014-05-26  2:35 ` Ben Hutchings
2014-05-26 11:05   ` Jamal Hadi Salim [this message]
2014-05-30  5:08     ` David Miller

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=53831FDD.4020902@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=ben@decadent.org.uk \
    --cc=davem@davemloft.net \
    --cc=john.r.fastabend@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=sfeldma@cumulusnetworks.com \
    --cc=stephen@networkplumber.org \
    --cc=vyasevic@redhat.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.