Thanks a ton Neale for sharing the detailed view. From the example you mentioned, “to send to a GRE interface for output if a classifier is matched”, can I configure this classifier using VPP constructs i.e. policy-classifier/ACL/N-tuple-classifier(https://wiki.fd.io/view/VPP/Introduction_To_N-tuple_Classifiers) ?
My use-case also involves ‘extract’ a packet that matches some criteria. For e.g., matching particular fields (DMAC, ether-type, port, etc) in the packet with the value-of-interest. Thanks, Leela sankar From: <vpp-dev@lists.fd.io> on behalf of "Neale Ranns via Lists.Fd.Io" <nranns=cisco....@lists.fd.io> Reply-To: "nra...@cisco.com" <nra...@cisco.com> Date: Wednesday, February 6, 2019 at 10:51 PM To: Leela Gudimetla <lgudi...@ciena.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Subject: Re: [**EXTERNAL**] [vpp-dev] Understanding feature-arcs & features the vlib graph is a completely free form directed and acyclic. Meaning you can construct a graph of any nodes ‘pointing’ to any other. A router or switch has a well-known set of functions and so a graph is built in VPP to implement these functions. This graph is typically referred to as the L3 or L2 switch path. In order for you to augment this switch-path you need to hook your node into the existing graph. Using vlib functions you could build a edge from any node in the switch path to point to your new node, say from ip4-input to my-node, however, without modifications to ip4-input to ‘classify’ packets of interest there is no way a packet would make it to your node. The community is unlikely to accept changes to ip4-input and indeed any other node on the switch-path as they are performance critical. This is what feature arcs are for. A ‘feature’ in this context is any subsystem/module/etc that wants to see/modify/fiddle with the packet as it traverses the switch-path. A feature arc is a sub-graph of nodes – maybe graph is too flexible a word in this context as it’s really only an ordered linear set, or pipeline, of nodes. A feature-arc is rooted, or begins, at one of the nodes defined in the switch-path and ends at the next node in the switch-path (one can imagine it starting and ending at the same node and then immediately moving onto the next). Any node on the arc has the usual choice of sending the packet to the next node of its choice, e.g. to send to a GRE interface for output if a classifier matched, or drop it, and thus ‘extract’ the packet from the switch-path, or it can select the next feature/node on the arc so the packet can continue along the switch-path. The L2 and L3 switch-path both have feature arcs that are rooted at different places (see slide 15 of the attached deck for L3). How you use a feature-arc is well described in the wiki you reference. Benoit recently added a neat feature that allows you to visualise the graph; show vlib graphviz which might help you understand the monsters you create 😉 /neale De : <vpp-dev@lists.fd.io> au nom de "Gudimetla, Leela Sankar" <lgudi...@ciena.com> Date : jeudi 7 février 2019 à 02:43 À : "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Objet : Re: [**EXTERNAL**] [vpp-dev] Understanding feature-arcs & features Dave/Neale, Sharing any details would help to understand better on top of ‘use the force and read the source’. Thanks, Leela sankar From: <vpp-dev@lists.fd.io> on behalf of Leela Gudimetla <lgudi...@ciena.com> Date: Wednesday, February 6, 2019 at 11:35 AM To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Subject: [**EXTERNAL**] [vpp-dev] Understanding feature-arcs & features Hello All, I have a use case with VPP as below. 1. Need to send customized packets (similar to some L3 control packets. ARP, ICMP, etc) from ‘my-node’ to loopback. 2. The loopback interface is attached to a bridge-domain. So, the customized packets need to be either flooded in the bridge-domain or sent on a particular interface based on the destination-MAC in the packet. From the code-walk, I see that loopback-interface has a set of nodes i.e. ‘output-node’ and ‘tx-node’ created as part of interface creation. And I also see that the loopback-interface tx-node is added next to its output-node. And the output-node is added to ‘interface-output’ feature-arc. I looked at the https://wiki.fd.io/view/VPP/Feature_Arcs and also lot of code that does VPP_FEATURE_ARC_INIT & VPP_FEATURE_INIT, to get a clear understanding on how my customized packet would traverse the VPP’s node graph. But somehow I am missing the full packet traversal after the loopback-interface’s output-node. Could someone share details on how the feature-arcs and ‘features that use the feature-arcs’ work? And to be specific how the ‘interface-output’ feature-arc works in order to send the packet out from loopback-interface output-node to the corresponding NIC? And why is that ‘tx-node’ needed/used? Too many questions, but any help understanding the flow would really help. Thanks, Leela sankar
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12209): https://lists.fd.io/g/vpp-dev/message/12209 Mute This Topic: https://lists.fd.io/mt/29685539/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
