Hello Neale, Dave,
@Neale
I would like to apply my modifications and let ip4-rewrite apply its,
and compute the checksum (once). I don't want to replace it for the
reason you cited (MTU, etc) .I don't want to put my node after
ip4-rewrite, because i will apply my modifications, and have to
recompute the checksum.
Just to clarify and be sure that i am not off topic: my first node is an
extended version of the vnet/classify classifiers, the second one is a
rewrite node based on the classifier matchings.
@Dave
This solution looks good to me. I'm going to give a try.
Thanks
Korian
On 01/18/2018 01:57 PM, Dave Barach (dbarach) wrote:
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
--
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
