[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e3ac4e3535a18f6dd1cf31030674f91c.squirrel@poczta.wsisiz.edu.pl>
Date: Wed, 17 Dec 2014 16:18:11 -0000
From: "Hubert Sokolowski" <h.sokolowski@....edu.pl>
To: vyasevic@...hat.com
Cc: "John Fastabend" <john.fastabend@...il.com>,
"Jamal Hadi Salim" <jhs@...atatu.com>,
"Roopa Prabhu" <roopa@...ulusnetworks.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if
ndo_fdb_dump is defined.
>
> I don't think we have to dump uc/mc lists unconditionally. What we
> want is the lower diver's view of any fdb entries it things are appropriate.
> For simple cards, this becomes equivalent to uc/mc lists. For smarter cards
> that override the default dumper, it makes sense for them to provide the info.
>
I am very glad to hear that :).
>
> Well, the bridge would have dumped any fdbs that pointer at the bridge
> device (port is NULL) as it's egress port. Not sure about the vxlan.
> For stacked situations of complex devices this make sense. For
> instance if you stack vxlan on top of bridge, then from the vxlan
> perspective, we want to see what macs the bridge will forward to the
> vxlan. Here, the bridge is actually slightly broken as it wouldn't
> actually dump all the pertinent info, but that's more of a bridge problem.
I have just prepared a patch where I dump uc/mc for bridge devices
by looking at (dev->priv_flags & IFF_EBRIDGE), so I have same results
as without my changes. This should satisfy Jamal and Roopa.
I could send it as v3 of my patch along with the results if you are
interested.
>
> -vlad
>
thanks,
Hubert
--
Hubert Sokolowski Intel Corporation
--
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