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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0dd2e57a61d618984648a3bf6373728f61a8fecf.camel@nvidia.com>
Date:   Tue, 27 Oct 2020 15:09:27 +0000
From:   Nikolay Aleksandrov <nikolay@...dia.com>
To:     "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "bridge@...ts.linux-foundation.org" 
        <bridge@...ts.linux-foundation.org>
CC:     "henrik.bjoernlund@...rochip.com" <henrik.bjoernlund@...rochip.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Roopa Prabhu <roopa@...dia.com>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "horatiu.vultur@...rochip.com" <horatiu.vultur@...rochip.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>
Subject: Re: [Bridge] [PATCH net-next v7 01/10] net: bridge: extend the
 process of special frames

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@...ts.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