[vpp-dev] Regarding vlib_buffer_t metadata
Hi, I am writing a plugin node which will get packets the usual way. I will pipeline these packets between my worker threads (in the same plugin node) using the handoff mechanism available. Thus, when my plugin node gets a packet, it could have been from an internal handoff from one of my workers or it could be from anywhere else (eg. ip4-input). Question is, how can I safely distinguish what kind of a packet it is i.e. is it coming because of handoff or from an external node not due to a handoff ? It is clear that I can setup one of the opaque fields of vlib_buffer_t to some non zero custom values when I do internal handoff and then inspect at packet reception at my node. I will also set these back to zero when I am sending the packet to any other node. But are they guaranteed to be zero when the packet originates from the dpdk plugin and then via traversal eventually lands up at my node for the first time ? Regards -Prashant -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11085): https://lists.fd.io/g/vpp-dev/message/11085 Mute This Topic: https://lists.fd.io/mt/27845920/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Incrementing node counters
Thanks for the education. will look into the assembly code.
原始邮件
主题： Re: [vpp-dev] Incrementing node counters
来自： "Dave Barach via Lists.Fd.Io"
发至： 2018年11月3日 下午7:55
抄送： Kingwel Xie ,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
Date: Saturday, November 3, 2018 at 3:57 AM
To: Recipient Suppressed , "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)"
发至： 2018年11月2日 下午7:00
抄送： Kingwel Xie ,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)
{
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;
}
}
}
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 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]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Incrementing node counters
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
Date: Saturday, November 3, 2018 at 3:57 AM
To: Recipient Suppressed , "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)"
发至： 2018年11月2日 下午7:00
抄送： Kingwel Xie ,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)
{
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;
}
}
}
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 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 (#11083): https://lists.fd.io/g/vpp-dev/message/11083
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]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] 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)"
发至： 2018年11月2日 下午7:00
抄送： Kingwel Xie ,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)
{
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;
}
}
}
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 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 (#11082): https://lists.fd.io/g/vpp-dev/message/11082
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]
-=-=-=-=-=-=-=-=-=-=-=-
