Hi Tomas,
> But how does af-packet-input decide which of these nodes to run? Is
it simply in descending order so since sample is at the bottom, it will
be run before ethernet-input etc?
If the device produce's ptype & ethtype information, dpdk-input will use
this to identify the next node for any given packet. If not it will
identify the packet's ptype in software.
As I remember
.runs_before = VNET_FEATURES ("ethernet-input"),
Causes the sample plugin to hook itself in front of the ethernet-input
graph node. The tracing facility is revealing for this kind of
understanding.
Ray K
On 16/05/2017 09:55, Tomas Brännström wrote:
Hi
I'm struggling a bit to understand how VPP processes the node graph. If
we take the sample plugin for example, it registers itself to the
"device-input" arc. Then it is run after "af-packet-input" among others.
But looking at the af-packet-input-node, it has the following "next"
nodes in the graph:
af-packet-input ip4-input-no-checksum [0]
ip4-input [1]
ip6-input [2]
mpls-input [3]
ethernet-input [4]
error-drop [5]
sample [6]
But how does af-packet-input decide which of these nodes to run? Is it
simply in descending order so since sample is at the bottom, it will be
run before ethernet-input etc?
Also, is there a document somewhere that explains exactly how a node is
input into the graph? I think I understand how it works on some level,
but I'm not 100% clear what for example VPP actually does with
".arc_name", ".runs_before" and so on.
/Tomas
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
