All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	vyasevic@redhat.com,
	Stephen Hemminger <stephen@networkplumber.org>,
	Scott Feldman <sfeldma@cumulusnetworks.com>,
	John Fastabend <john.r.fastabend@intel.com>
Subject: Re: RFC: bridge get fdb by bridge device
Date: Tue, 11 Feb 2014 12:03:49 -0500	[thread overview]
Message-ID: <52FA57F5.3080400@mojatatu.com> (raw)
In-Reply-To: <52F7D7EE.7010302@gmail.com>

On 02/09/14 14:33, John Fastabend wrote:
> On 02/09/2014 07:06 AM, Jamal Hadi Salim wrote:

>
>> +    if (ndm->ndm_ifindex) {
>> +        dev = __dev_get_by_index(net, ndm->ndm_ifindex);
>> +        if (dev == NULL) {
>> +            pr_info("PF_BRIDGE: RTM_GETNEIGH with unknown ifindex\n");
>> +            return -ENODEV;
>> +        }
>> +
>> +        if (!(dev->priv_flags & IFF_EBRIDGE)) {
>
> Can we drop this 'if case' and just use the 'if (ops->ndo_fdb_dump)'
> below? IFF_EBRIDGE is specific to ./net/bridge so it will fail for
> macvlans and I think the command is useful in both cases.
>

My only worry is:
The target ndm_ifindex is to a bridge device i.e something
that has an "fdb" (user space says "br X" then we use X to
mean we are talking about a bridge device. This is what
brctl showmacs <X> means.
I know this doesnt seem right relative to current point of
view where the target is the bridge port ifindex.
I'd be more than happy to make the change if it makes sense,
but i am struggling with that thought.

>
>> +            pr_info("PF_BRIDGE: RTM_GETNEIGH %s not a bridge device\n",
>> +                dev->name);
>> +            return -EINVAL;
>>          }
>> +        ops = dev->netdev_ops;
>> +        if (ops->ndo_fdb_dump) {
>> +            idx = ops->ndo_fdb_dump(skb, cb, dev, idx);
>> +        } else {
>
> Is there any problem with using the ndo_dflt_fdb_dump() in the else
> here?
>

If the assumption is the target ifindex is to a bridge device, I would
expect it MUST have a ops->ndo_fdb_dump(), no?
the default dumper deals with bridge ports (which may be bridges, but
if i wanted their databases i would address them)

> Userspace should be able to easily learn which ports are ebridge ports
> so I don't think that should be an issue. Anyways with the above
> IFF_EBRIDGE check you should never hit this else case although I think
> its safe to drop the above check as noted.
>

Right - so if i can find out which is an ebridge i can send it the
same request.

cheers,
jamal

  reply	other threads:[~2014-02-11 17:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <52F21F72.2090405@mojatatu.com>
     [not found] ` <52F29747.7040008@redhat.com>
     [not found]   ` <52F3CF76.9090404@mojatatu.com>
     [not found]     ` <52F3E357.4040006@redhat.com>
2014-02-09 15:06       ` RFC: bridge get fdb by bridge device Jamal Hadi Salim
2014-02-09 19:33         ` John Fastabend
2014-02-11 17:03           ` Jamal Hadi Salim [this message]
2014-02-10 16:31         ` Vlad Yasevich
2014-02-11 17:07           ` Jamal Hadi Salim
2014-02-11 18:21             ` Vlad Yasevich
2014-02-11 20:15               ` Jamal Hadi Salim
2014-02-11 20:21                 ` John Fastabend
2014-02-11 20:30                 ` John Fastabend
2014-02-11 21:04                   ` Jamal Hadi Salim
2014-02-12 18:50                     ` John Fastabend
2014-02-13 12:50                       ` Jamal Hadi Salim
2014-02-13 15:37                       ` Jamal Hadi Salim
2014-02-13 16:03                         ` John Fastabend
2014-02-11 21:00                 ` Vlad Yasevich
2014-02-11 21:08                   ` Jamal Hadi Salim
2014-02-11 21:12                     ` Jamal Hadi Salim
2014-02-12 19:02                     ` 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=52FA57F5.3080400@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=john.fastabend@gmail.com \
    --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.