lkml.org 
[lkml]   [2020]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Bridge] [PATCH net-next v7 01/10] net: bridge: extend the process of special frames
Date
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


\
 
 \ /
  Last update: 2020-10-27 17:11    [W:0.069 / U:2.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site