netdev - Re: [patch net-next v3 00/15] introduce programable flow dissector and cls

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] [day] [month] [year] [list]

Message-ID: <20150514094437.GC2197@nanopsycho.mtl.com>
Date:	Thu, 14 May 2015 11:44:37 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	David Miller <davem@...emloft.net>
Cc:	tom@...bertland.com, netdev@...r.kernel.org, jhs@...atatu.com,
	tgraf@...g.ch, jesse@...ira.com, kaber@...sh.net,
	edumazet@...gle.com, alexander.h.duyck@...hat.com,
	hannes@...essinduktion.org, ast@...mgrid.com, daniel@...earbox.net,
	herbert@...dor.apana.org.au, cwang@...pensource.com,
	john.fastabend@...il.com
Subject: Re: [patch net-next v3 00/15] introduce programable flow dissector
 and cls_flower

Wed, May 13, 2015 at 10:01:48PM CEST, davem@...emloft.net wrote:
>From: Tom Herbert <tom@...bertland.com>
>Date: Wed, 13 May 2015 15:27:59 -0400
>
>>> I'm sure there will be some performance improvements possible, and I
>>> hope you will look into making sure this new programmable classifier
>>> is as light weight as possible.
> ...
>
>> I still have concerns about making flow_dissector more complex like
>> this. This still seems like it should this programmable logic be done
>> in a separate function. We call flow_dissector at least once per
>> packet via skb_get_hash, it is in the critical path, and adding
>> several conditionals can only slow it down and provides no new value
>> to skb_get_hash. At the very least can we at least get some
>> performance numbers to show impact of this?
>
>The part of what I said to Jiri above is meant exactly to ensure that
>he handles this.
>
>If we need a specialized fast path for the skb_get_hash() code paths,
>so be it.
>
>But I'm not going to denouce his entire efforts for something that
>hasn't even been shown to be an issue yet.  And if it is, I'm sure
>Jiri will work to address it.

Yes, sure thing.

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