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  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]
Date:   Tue, 3 Aug 2021 18:06:33 +0200 (CEST)
From:   Justin Iurman <>
To:     Eric Dumazet <>
Subject: Re: [RFC net-next] ipv6: Attempt to improve options code parsing

>> As per Eric's comment on a previous patchset that was adding a new HopbyHop
>> option, i.e. why should a new option appear before or after existing ones in the
>> list, here is an attempt to suppress such competition. It also improves the
>> efficiency and fasten the process of matching a Hbh or Dst option, which is
>> probably something we want regarding the list of new options that could quickly
>> grow in the future.
>> Basically, the two "lists" of options (Hbh and Dst) are replaced by two arrays.
>> Each array has a size of 256 (for each code point). Each code point points to a
>> function to process its specific option.
>> Thoughts?
> Hi Justin
> I think this still suffers from indirect call costs (CONFIG_RETPOLINE=y),
> and eventually use more dcache.

Agree with both. It was the compromise for such a solution, unfortunately.

> Since we only deal with two sets/arrays, I would simply get rid of them
> and inline the code using two switch() clauses.

Indeed, this is the more efficient. However, we still have two "issues":
 - ip6_parse_tlv will keep growing and code could look ugly at some point
 - there is still a "competition" between options, i.e. "I want to be at the top of the list"

Anyway, your solution is better than the current one so it's probably the way to go right now.

Powered by blists - more mailing lists