Thanks for the education. will look into the assembly code.
-------- 原始邮件 --------
主题： Re: [vpp-dev] Incrementing node counters
来自： "Dave Barach via Lists.Fd.Io" <dbarach=cisco....@lists.fd.io>
发至： 2018年11月3日 下午7:55
抄送： Kingwel Xie <kingwel....@ericsson.com>,vpp-dev@lists.fd.io
You’ll have to look at the instruction stream in gdb or else “gcc –S” and look
at the generated assembly-language code. Even at that, the difference in clock
cycles won’t be completely obvious due to subarchitectural CPU implementation
details. “Node” is not a typical hot variable which would end up in a register.
It probably makes exactly zero difference.
FWIW… Dave
From: Kingwel Xie <kingwel....@ericsson.com>
Date: Saturday, November 3, 2018 at 3:57 AM
To: Recipient Suppressed <dbar...@cisco.com>, "vpp-dev@lists.fd.io"
<vpp-dev@lists.fd.io>
Subject: RE: Incrementing node counters
Thanks for the comments.
I know is_ip6 will be optimized by complier.
I am still wondering how different between using xxx_node.index and
node->node_index. Anyway,thanks, now I understand it is a performance
consideration.
Best Regards,
Kingwel
-------- 原始邮件 --------
主题： RE: Incrementing node counters
来自： "Dave Barach (dbarach)" <dbar...@cisco.com>
发至： 2018年11月2日 下午7:00
抄送： Kingwel Xie <kingwel....@ericsson.com>,vpp-dev@lists.fd.io
Yes, you missed something. This pattern is used in inline functions called with
compile-time constant values for is_ip6:
always_inline uword
ah_encrypt_inline (vlib_main_t * vm,
vlib_node_runtime_t * node, vlib_frame_t * from_frame,
int is_ip6)
VLIB_NODE_FN (ah4_encrypt_node) (vlib_main_t * vm,
vlib_node_runtime_t * node,
vlib_frame_t * from_frame)
{
return ah_encrypt_inline (vm, node, from_frame, 0 /* is_ip6 */ );
}
VLIB_NODE_FN (ah6_encrypt_node) (vlib_main_t * vm,
vlib_node_runtime_t * node,
vlib_frame_t * from_frame)
{
return ah_encrypt_inline (vm, node, from_frame, 1 /* is_ip6 */ );
}
The compiler discards either the “if” clause or the “else” clause, and
(certainly) never tests is_ip6 at runtime. It might be marginally worth
s/xxx_node.index/node->node_index/.
Another instance of this game may make sense in performance-critical nodes.
Here, we remove packet-tracer code:
always_inline uword
nsim_inline (vlib_main_t * vm,
vlib_node_runtime_t * node, vlib_frame_t * frame, int is_trace)
{
<snip>
if (is_trace)
{
if (b[0]->flags & VLIB_BUFFER_IS_TRACED)
{
nsim_trace_t *t = vlib_add_trace (vm, node, b[0], sizeof (*t));
t->expires = expires;
t->is_drop = is_drop0;
t->tx_sw_if_index = (is_drop0 == 0) ? ep->tx_sw_if_index : 0;
}
}
<snip>
}
VLIB_NODE_FN (nsim_node) (vlib_main_t * vm, vlib_node_runtime_t * node,
vlib_frame_t * frame)
{
if (PREDICT_FALSE (node->flags & VLIB_NODE_FLAG_TRACE))
return nsim_inline (vm, node, frame, 1 /* is_trace */ );
else
return nsim_inline (vm, node, frame, 0 /* is_trace */ );
}
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Kingwel Xie
Sent: Thursday, November 1, 2018 8:43 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Incrementing node counters
Hi vPPers,
I’m looking at the latest changes in IPSEC, and I notice ip4 and ip6 nodes are
separated. So there are a lot of code in the node function like this:
if (is_ip6)
vlib_node_increment_counter (vm, esp6_decrypt_node.index,
ESP_DECRYPT_ERROR_RX_PKTS,
from_frame->n_vectors);
else
vlib_node_increment_counter (vm, esp4_decrypt_node.index,
ESP_DECRYPT_ERROR_RX_PKTS,
from_frame->n_vectors);
I’m wondering why not like this:
vlib_node_increment_counter (vm, node->node_index,
ESP_DECRYPT_ERROR_RX_PKTS,
from_frame->n_vectors);
My understanding is that node functions are always dispatched with the correct
node instances. Or do I miss something? BTW, nt just ipsec, quite some other
nodes are written as the former.
Regards,
Kingwel
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11084): https://lists.fd.io/g/vpp-dev/message/11084
Mute This Topic: https://lists.fd.io/mt/27823101/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
