[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201124112430.64143482@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Tue, 24 Nov 2020 11:24:30 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: wenxu@...oud.cn
Cc: marcelo.leitner@...il.com, vladbu@...dia.com, jhs@...atatu.com,
xiyou.wangcong@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH v3 net-next 3/3] net/sched: sch_frag: add generic packet
fragment support.
On Fri, 20 Nov 2020 07:38:36 +0800 wenxu@...oud.cn wrote:
> +int tcf_dev_queue_xmit(struct sk_buff *skb, int (*xmit)(struct sk_buff *skb))
> +{
> + xmit_hook_func *xmit_hook;
> +
> + xmit_hook = rcu_dereference(tcf_xmit_hook);
> + if (xmit_hook)
> + return xmit_hook(skb, xmit);
> + else
> + return xmit(skb);
> +}
> +EXPORT_SYMBOL_GPL(tcf_dev_queue_xmit);
I'm concerned about the performance impact of these indirect calls.
Did you check what code compiler will generate? What the impact with
retpolines enabled is going to be?
Now that sch_frag is no longer a module this could be simplified.
First of all - xmit_hook can only be sch_frag_xmit_hook, so please use
that directly.
if (READ_ONCE(tcf_xmit_hook_count))
sch_frag_xmit_hook(...
else
dev_queue_xmit(...
The abstraction is costly and not necessary right now IMO.
Then probably the counter should be:
u32 __read_mostly tcf_xmit_hook_count;
To avoid byte loads and having it be places in an unlucky cache line.
You could also make the helper a static inline in a header.
Unless I'm not giving the compiler enough credit and the performance
impact of this patch with retpolines on is indiscernible, but that'd
need to be proven by testing...
Powered by blists - more mailing lists