netdev - Use of Indirect function calls

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

Message-ID: <98ed174f-2c55-7612-ad07-56557210602e@oracle.com>
Date:   Tue, 6 Mar 2018 19:35:46 -0800
From:   Rao Shoaib <rao.shoaib@...cle.com>
To:     netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
        Eric Dumazet <eric.dumazet@...il.com>
Subject: Use of Indirect function calls

I am working on a change which introduces a couple of indirect function 
calls in the fast path. I used indirect function calls instead of 
"if/else" as it keeps the code cleaner and more readable and provides 
for extensibility.

I do not expect any measurable overhead as modern CPU's use pre-fetching 
and multiple parallel execution engines. Indirect jump prediction has 
gotten very good too. Assembly shows that the difference is an 
instruction to get the table address followed by a call to *callq 
instead of callq. I could not find official Intel numbers[1] but third 
party numbers suggest that *callq may have an over head of 1 clock 
cycle. Over head of accessing the table address is similar to reading a 
variable or testing a flag.

Will a patch that introduces indirect function calls be rejected just 
because it uses indirect function calls in the fast path or is the 
use/impact evaluated on a case by case basis ? I do see usage of 
indirect function calls in TCP fast path and Ethernet drivers so it 
can't be that bad.

Regards,

Shoaib

[1] I believe this is because the instruction is broken down into 
multiple uops and due to perfecting and parallel execution the latency 
is hard to measure.