netdev - Re: DSA and ptp_classify_raw: saving some CPU cycles causes worse throughput?

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]

Date:   Wed, 4 Nov 2020 04:05:02 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: DSA and ptp_classify_raw: saving some CPU cycles causes worse
 throughput?

> My untrained eye tells me that in the 'after patch' case (the worse
> one), there are less branch misses, and less cache misses. So by all
> perf metrics, the throughput should be better, but it isn't. What gives?

Maybe the frame has been pushed out of the L1 cache. The classify code
is pulling it back in. It suffers some cache misses to get what it
needs, but also in the background some speculative cache loads also
happen, which are 'free'. By the time the DSA tagger is called, which
also needs the header in the frame, it is all in L1 and the taggers
work is fast.

Without the classify, the tagger is getting a cold cache. And it ends
up waiting around longer since it cannot benefit from the speculative
'free' loads?

In your little patch, rather than a plain return, try calling
prefetch() on the skb data so it might be warm by the time the tagger
needs to manipulate it.

      Andrew