On Tue, 2020-10-27 at 07:59 -0700, Stephen Hemminger wrote:
> On Tue, 27 Oct 2020 10:02:42 +0000
> Henrik Bjoernlund via Bridge <bri...@lists.linux-foundation.org> wrote:
>
> > +/* Return 0 if the frame was not processed otherwise 1
> > + * note: already called with rcu_read_lock
> > + */
> > +static int br_process_frame_type(struct net_bridge_port *p,
> > + struct sk_buff *skb)
> > +{
> > + struct br_frame_type *tmp;
> > +
> > + hlist_for_each_entry_rcu(tmp, &p->br->frame_type_list, list)
> > + if (unlikely(tmp->type == skb->protocol))
> > + return tmp->frame_handler(p, skb);
> > +
> > + return 0;
> > +}
>
> Does the linear search of frame types have noticable impact on performance?
> Hint: maybe a bitmap or something would be faster.
I don't think it's necessary to optimize it so early. There are only 2 possible
types so far (with this set included) if CfM and MRP both are in use, if at some
point it grows we can turn it into a hash or bitmap, at the moment a simple and
easier to maintain solution seems better to me. We could mask the search itself
behind a static key and do it only if a protocol is registered to minimize the
impact further.
Cheers,
Nik
