Here's one way to solve the problem, which should result in a patch we can 
merge:



  *   Add head-of-feature-arc processing to ip4/6_lookup_inline() under control 
of an integer argument [which will be passed as a constant 0 or 1].
  *   Create a couple of new nodes “ip4-lookup-with-post-lookup-arc” [or some 
better name] in ip4/6_forward.c, which instantiate the head of feature arc code
  *   Add the “…with-post-lookup-arc” nodes to the current pre-lookup rx 
feature arc, before the vanilla lookup nodes.
  *   Make the …with-post-lookup-arc” nodes siblings of the normal lookup 
nodes, so they inherit successor arcs/indices automatically.
  *   Add your node(s) to the post-lookup arc



To make traffic flow: enable the …with-post-lookup-arc nodes in the current rx 
feature arc AND enable your node(s) on the post-lookup arc



If done correctly, this should cost zero clock cycles in the speed path: a hard 
requirement.



HTH… D.



-----Original Message-----
From: korian edeline [mailto:korian.edel...@ulg.ac.be]
Sent: Thursday, January 18, 2018 6:37 AM
To: Neale Ranns (nranns) <nra...@cisco.com>; Dave Barach (dbarach) 
<dbar...@cisco.com>; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Create an arc



Hello Neale, Dave,



Thanks for your answers.



I would like to catch all (not on a prefix basis) traffic to-be-forwarded.

- I would need the TX sw_if_index, so i think the nodes should be placed after 
ip4-lookup.

- i have to be before ip4-rewrite, not to compute checksums 2 times.



Right now, my nodes are placed before lookup, via ip4-unicast feature arc and 
they can be enabled/disabled via vnet_feature_enable_disable.

Something similar, but after lookup, would be really convenient.



Regards,

Korian



On 01/18/2018 11:01 AM, Neale Ranns (nranns) wrote:

> Hi Korian,

>

> Constructing the VLIB graph between ipX-lookup and ipX-rewrite (and really to 
> interface-output) is best achieved by following the DPO architecture. You can 
> read a little about it here:

>    https://wiki.fd.io/view/VPP/DPOs_and_Feature_Arcs

>

> Step one is to implement a new DPOs to represent your two new nodes. You’ll 
> find many examples of DPOs in vnet/dpo/*. Step 2 is then to ‘resolve’ the IP 
> prefix via your DPO. The means for that is, e.g, from vnet/bier/bier_table.c:

>

>          bt->bt_lfei = fib_table_entry_special_dpo_add(mpls_fib_index,

>                                                        &pfx,

>                                                        FIB_SOURCE_BIER,

>                                                        
> FIB_ENTRY_FLAG_EXCLUSIVE,

>                                                        &dpo);

>

> the rather badly named EXCLUSIVE flag means the caller is providing the DPO 
> and so FIB has no need to perform its usual resolution. The FIB_SOURCE_BIER 
> identifies ‘who’ is providing the forwarding information (the DPO) and thus 
> the relative priority of that information. There is a simple linear priority 
> scheme among the sources enumerated by fib_source_t.

> Step 3 is to ‘stack’ your DPOs, i.e. to form the chain/graph that will be 
> followed in the data-plane. The FIB API above automatically stacks the 
> load_balance_t DPO (which is the result of the lookup) on your DPO passed.

>

> note that the above provides you with ‘override’ semantics, i.e. for a given 
> prefix you can override (assuming your source has higher priority) the 
> existing forwarding information for that prefix. If instead your requirements 
> are to apply further rules/checks/replications on the packets before they are 
> forwarded using the existing information, then this is what I call 
> ‘interposition’. I have an outstanding patch for this:

>    https://gerrit.fd.io/r/#/c/9336/

> I’ll try and get it finished soon.

>

> The last issue to consider is whether your override or interposition needs to 
> affect only the prefix you specify in the call to 
> fib_table_entry_special_dpo_add() or to all longer mask prefixes that it 
> covers. For example, if you specify 10.0.0.0/24, and some other source 
> specifies 10.0.0.0/25 and 10.128.0.0/25 then your prefix is never matched. In 
> order to ‘push’ your forwarding down to all longer mask prefixes in the 
> sub-tree one needs to explicitly specify this. Again, this is an outstanding 
> patch:

>   https://gerrit.fd.io/r/#/c/9477/

>

>

> Having said all that, if what you are after Is not running your

> feature on a per-prefix basis, but instead on a per-output interface

> basis, then you want the ip4-output feature arc ☺

>

> hth,

> neale

>

>

> -----Original Message-----

> From: "Dave Barach (dbarach)" <dbar...@cisco.com<mailto:dbar...@cisco.com>>

> Date: Wednesday, 17 January 2018 at 16:21

> To: korian edeline 
> <korian.edel...@ulg.ac.be<mailto:korian.edel...@ulg.ac.be>>, 
> "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>"

> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>, "Neale Ranns (nranns)" 
> <nra...@cisco.com<mailto:nra...@cisco.com>>

> Subject: RE: [vpp-dev] Create an arc

>

>      Dear Korian,

>

>      Steering traffic from ip4_lookup to <some-node> is easily accomplished 
> by setting the fib result [dpo->dpoi_next_node] to send matching traffic 
> where you want it to go.

>

>      Add an arc from ip4/6_lookup to <some-node> by calling 
> vlib_node_add_next(...) to create the arc, then create fib entries with 
> dpoi_next_node set to the returned next_index.

>

>      This is not a feature arc problem. Attempting to solve it as such will 
> cause no end of trouble.

>

>      Neale, please jump in as needed...

>

>      HTH... Dave

>

>      -----Original Message-----

>      From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of korian edeline

>      Sent: Wednesday, January 17, 2018 9:30 AM

>      To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>

>      Subject: [vpp-dev] Create an arc

>

>      Hi all,

>

>      Here is the deal:

>

>      I have 2 nodes (my-node-1, my-node-2),  I would like my-node-1 to 
> receive packets from ip4-lookup, forwarding to either ip4-rewrite, error-drop 
> or my-node-2. my-node-2 should only receive from my-node-1 and forward to 
> ip4-rewrite or error-drop.

>

>      If I put them BEFORE ip4-lookup, i can use pre-built arc ip4-unicast and 
> everything works perfect. But i figured that if i want them after ip4-lookup, 
> i have to create my own arc. So here is what i have, plus replacing 
> occurences of "ip4-unicast" by "my-arc".

>

>      VNET_FEATURE_ARC_INIT (my_arc, static) = {

>         .arc_name = "my-arc,

>         .start_nodes = VNET_FEATURES ("ip4-lookup"),

>         .arc_index_ptr = &my_main.feature_arc_index };

>

>      What am i missing  ?

>

>      Thanks

>

>      Korian

>

>      _______________________________________________

>      vpp-dev mailing list

>      vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>

>      https://lists.fd.io/mailman/listinfo/vpp-dev

>

>



--



Korian Edeline

Université de Liège (ULg)

Bât. B28  Algorithmique des Grands Systèmes Quartier Polytech 1 Allée de la 
Découverte 10

4000 Liège

Phone: +32 4 366 56 05


_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Reply via email to