On Wed, Dec 8, 2021 at 5:47 AM Hou Tao [off-list ref] wrote:
Hi,
On 12/7/2021 11:01 AM, Andrii Nakryiko wrote:
quoted
On Tue, Nov 30, 2021 at 6:07 AM Hou Tao [off-list ref] wrote:
quoted
Add benchmark to compare the performance between home-made strncmp()
in bpf program and bpf_strncmp() helper. In summary, the performance
win of bpf_strncmp() under x86-64 is greater than 18% when the compared
string length is greater than 64, and is 179% when the length is 4095.
Under arm64 the performance win is even bigger: 33% when the length
is greater than 64 and 600% when the length is 4095.
snip
quoted
quoted
+
+long hits = 0;
+char str[STRNCMP_STR_SZ];
+
+char _license[] SEC("license") = "GPL";
+
+static __always_inline int local_strncmp(const char *s1, unsigned int sz,
+ const char *s2)
+{
+ int ret = 0;
+ unsigned int i;
+
+ for (i = 0; i < sz; i++) {
+ /* E.g. 0xff > 0x31 */
+ ret = (unsigned char)s1[i] - (unsigned char)s2[i];
I'm actually not sure if it will perform subtraction in unsigned form
(and thus you'll never have a negative result) and then cast to int,
or not. Why not cast to int instead of unsigned char to be sure?
It is used to handle the character which is greater than or equal with 0x80.
When casting these character into int, the result will be a negative value,
the compare result will always be negative and it is wrong because
0xff should be greater than 0x31.
I see about (unsigned char) cast, but I was worried that subtraction
result won't be negative I've tested with
$ cat test.c
#include <stdio.h>
int main() {
int x = (unsigned char)190 - (unsigned char)255;
printf("%d\n", x);
}
Seems like it behaves sanely (at least on this particular compiler),
so I'm fine with it.