Re: [Bridge] [PATCH net-next v7 01/10] net: bridge: extend the process of special frames

[Nikolay Aleksandrov <nikolay@nvidia.com>]

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 <bridge@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