netdev - Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.

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:   Thu, 8 Dec 2016 10:59:47 +0100
From:   Nicolas Ferre <nicolas.ferre@...el.com>
To:     Richard Cochran <richardcochran@...il.com>,
        Andrei Pistirica <andrei.pistirica@...rochip.com>
CC:     <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <davem@...emloft.net>,
        <harinikatakamlinux@...il.com>, <harini.katakam@...inx.com>,
        <punnaia@...inx.com>, <michals@...inx.com>, <anirudh@...inx.com>,
        <boris.brezillon@...e-electrons.com>,
        <alexandre.belloni@...e-electrons.com>, <tbultel@...elsurmer.com>,
        <rafalo@...ence.com>
Subject: Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence
 GEM.

Le 07/12/2016 à 20:39, Richard Cochran a écrit :
> On Wed, Dec 07, 2016 at 08:21:51PM +0200, Andrei Pistirica wrote:
>> +#ifdef CONFIG_MACB_USE_HWSTAMP
>> +void gem_ptp_init(struct net_device *ndev);
>> +void gem_ptp_remove(struct net_device *ndev);
>> +
>> +void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb);
>> +void gem_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb);
> 
> These are in the hot path, and so you should do the test before
> calling the global function, something like this:
> 
> void gem_ptp_txstamp(struct macb *bp, struct sk_buff *skb);
> 
> static void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb)
> {
> 	if (!bp->hwts_tx_en)
> 		return;
> 	gem_ptp_txstamp(bp, skb);
> }
> 
> Ditto for Rx.

Hi Richard,

So you mean that as the "global" function won't be "inlined" by the
compiler as the function is not "static" neither in the same file and
that the jump will be implemented anyway. And this even if the function
is only called at a single location...

This way, if we add a kind or accessors function like the one that you
propose, with the test in it, the branch prediction can play his role
without breaking the processor pipeline as the accessors function will
be inlined by the compiler: Am I right?

So, yes, makes sense. Thanks for the hint.

Regards,
-- 
Nicolas Ferre