Re: [vpp-dev] Question regarding ip4/ip6 nexthop load balance flexibility #vnet
Hi Neale, Thanks for the clarification on the graph node usage (recursive vs non-recursive routes). Here are some of the characteristics of the situation we are interested in: 1. No recursive routes 2. For some of the schemes we need control on the hash calculation (ip_flow_hash_set may not meet our needs in those cases) 3. The approach #2 that you mention can be an option for some of the schemes. However we would need a large number of buckets (anywhere between 1K-32K depending on the situation). If we go down that path, we would need an atomic switch between the old bucket contents to the new bucket contents. 4. We have multiple VRFs and this scheme can vary depending on the VRF 5. In addition, even within the same VRF, different prefixes may be using different schemes (i.e. hashing and bucket selection). As far as the number of prefixes are concerned our use case isn't heavy on the number of routes/prefixes Hope this helps you providing the appropriate guidance on architecturally right way to make changes Thanks -Venky On Wed, Sep 8, 2021 at 4:55 AM Neale Ranns wrote: > Hi Venky, > > > > Which nodes get called depends on the nature of the route. Take this > trivial example > > > > DBGvpp# set int state loop0 up > > DBGvpp# set int ip addr loop0 10.0.0.1/24 > > > > This route is non recursive > > > > DBGvpp# ip route 1.1.1.1/32 via 10.0.0.2 loop0 > > > > This one is recursive > > > > DBGvpp# ip route 2.2.2.2/32 via 10.0.0.2 > > > > You can see the DPO graph built for them is different. > > > > DBGvpp# sh ip fib 1.1.1.1 > > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[recursive-resolution:1, default-route:1, ] > > 1.1.1.1/32 fib:0 index:11 locks:2 > > CLI refs:1 src-flags:added,contributing,active, > > path-list:[16] locks:2 flags:shared, uPRF-list:12 len:1 itfs:[1, ] > > path:[18] pl-index:16 ip4 weight=1 pref=0 attached-nexthop: > oper-flags:resolved, > > 10.0.0.2 loop0 > > [@0]: arp-ipv4: via 10.0.0.2 loop0 > > > > forwarding: unicast-ip4-chain > > [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12 to:[0:0]] > > [0] [@3]: arp-ipv4: via 10.0.0.2 loop0 > > > > This recursive prefix has an extra load-balanace object > > > > DBGvpp# sh ip fib 2.2.2.2 > > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[recursive-resolution:1, default-route:1, ] > > 2.2.2.2/32 fib:0 index:12 locks:2 > > CLI refs:1 src-flags:added,contributing,active, > > path-list:[18] locks:2 flags:shared, uPRF-list:15 len:1 itfs:[1, ] > > path:[20] pl-index:18 ip4 weight=1 pref=0 recursive: > oper-flags:resolved, > > via 10.0.0.2 in fib:0 via-fib:13 via-dpo:[dpo-load-balance:14] > > > > forwarding: unicast-ip4-chain > > [@0]: dpo-load-balance: [proto:ip4 index:15 buckets:1 uRPF:15 to:[0:0]] > > [0] [@12]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:14 > to:[0:0]]. <<<< HERE > > [0] [@3]: arp-ipv4: via 10.0.0.2 loop0 > > > > > > The first LB in the DPO graph will be the one used in ip4-lookup the > second one, when present, will be used in ip4-load-balance. > > > > The golden rule of forwarding is to do all the heavy lifting in the > control-plane so you can do the absolute minimum in the DP, because down > there extra work means worse performance. The load-balance bucket choice is > basically choice = buckets[flow-hash & n_buckets], which is the minimum we > can do. I would advise that you try and keep it this way by: > > 1 – choosing how the flow hash is calculated (see the list of ‘algorithms’ > available in ip_flow_hash_set) > > 2 – choosing in the CP how the buckets are populated. > > > > If 2. Is an option we can talk more about how you might go about doing > that > > Are you looking to change the bucket selection for all prefixes or most, > some or a few? > > > > /neale > > > > > > > > *From: *Venky Venkatesh > *Date: *Tuesday, 7 September 2021 at 20:11 > *To: *Neale Ranns > *Cc: *vpp-dev@lists.fd.io > *Subject: *Re: [vpp-dev] Question regarding ip4/ip6 nexthop load balance > flexibility #vnet > > Hi Neale, > > Thanks for getting back. I thought as much that cloning code (even though > I do a graph node replacement) wouldn't have been the way it would be done > by someone knowledgeable in the area. > > > > When I looked again at the code, the area I intended to change seems to be > a node in itself. *Is this code fo
Re: [vpp-dev] Question regarding ip4/ip6 nexthop load balance flexibility #vnet
Hi Neale,
Thanks for getting back. I thought as much that cloning code (even though I
do a graph node replacement) wouldn't have been the way it would be done by
someone knowledgeable in the area.
When I looked again at the code, the area I intended to change seems to be
a node in itself. *Is this code for ECMP? (appears to be like that)*
VLIB_REGISTER_NODE
<https://docs.fd.io/vpp/21.06/d0/da8/vlib_2node_8h.html#a025e3596085258b3bbd8e1a99ab026f4>
(ip4_load_balance_node
<https://docs.fd.io/vpp/21.06/dc/da9/ip4__forward_8c.html#a90b92667856f47252d614ba214ace26b>)
=
270 {
271 .name = "ip4-load-balance",
272 .vector_size = sizeof (u32
<https://docs.fd.io/vpp/21.06/de/deb/vppinfra_2types_8h.html#a162050b1a67fffab30498a67c9ab0f09>
),
273 .sibling_of = "ip4-lookup",
274 .format_trace = format_ip4_lookup_trace
<https://docs.fd.io/vpp/21.06/dc/da9/ip4__forward_8c.html#af59e7cb8282da4ff432f4237f1ab1e4a>
,
275 };
For some reason it doesn't show up in
https://docs.fd.io/vpp/21.06/d9/db0/nodes.html -- which is how I missed it
the 1st time around.
The localized changes that I was intending to do are in
load_balance_get_bucket_i and load_balance_get_fwd_bucket (i.e. having
computed the hash, the way I select the next hop could differ). I could
also entirely outsource the hash computation and nexthop calculation to my
code (in which case, also gets included in my changes).
The load_balance_* code gets invoked from ip4_lookup_* and also from
ip4_load_balance_*. Am I right that if I want to change the next hop
selection, I would replace ip4_load_balance_* with my implementation?
However I do not see this chained in the graph.
Look forward to your response
Thanks
-Venky
On Sun, Sep 5, 2021 at 6:52 AM Neale Ranns wrote:
>
>
> Hi Venky,
>
>
>
> There are several ways you might go about this but I would council that
> cloning code is a last resort – it would be a mainanence headache if you
> replace the current one or have i’s own set of challenges to use your
> replace node. if you could give me some more detail on how you want to
> change the next-hop selection I will gladly give you some specific advice.
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io on behalf of Venky
> Venkatesh via lists.fd.io
> *Date: *Wednesday, 1 September 2021 at 16:48
> *To: *vpp-dev@lists.fd.io
> *Subject: *[vpp-dev] Question regarding ip4/ip6 nexthop load balance
> flexibility #vnet
>
> Hi,
>
> I am new to fd.io
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__fd.io_=DwMF-g=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=w2W5SR0mU5u5mz008DZNCsexDN1Lr9bpL7ZGKuD0Zd4=bdaAaiMxrwSAEn2IzzNT7qwU8Iy_G-G-eQlabvZRaDM=zLAgC1KZL_0sC1trbkMPHqZrVJHEWT5__qCEOOVPJ1U=>.
> So pls pardon my ignorance.
>
> I wanted to experiment with different next hop selection algorithms once
> the destination IP is looked up. I looked at the ip4 code. My changes would
> be localized to how the nexthop is determined after the hash is calculated
> (currently it is going thru load_balance code). To my understanding it
> appears that ip4_lookup graph node has both the lookup and the next hop
> selection all bundled in one. If that is correct, then is the only way to
> try out alternate next hop selection algorithms be to create a graph node
> which is practically a clone of the ip4_lookup and then change the required
> portions in the cloned node code? If so, is this workflow in line with the
> way flexibility was intended?
>
> Any ideas welcome.
>
> Thanks
>
> -Venky
>
> #vnet
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20090): https://lists.fd.io/g/vpp-dev/message/20090
Mute This Topic: https://lists.fd.io/mt/85304201/21656
Mute #vnet:https://lists.fd.io/g/vpp-dev/mutehashtag/vnet
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Question regarding ip4/ip6 nexthop load balance flexibility #vnet
Hi, I am new to fd.io. So pls pardon my ignorance. I wanted to experiment with different next hop selection algorithms once the destination IP is looked up. I looked at the ip4 code. My changes would be localized to how the nexthop is determined after the hash is calculated (currently it is going thru load_balance code). To my understanding it appears that ip4_lookup graph node has both the lookup and the next hop selection all bundled in one. If that is correct, then is the only way to try out alternate next hop selection algorithms be to create a graph node which is practically a clone of the ip4_lookup and then change the required portions in the cloned node code? If so, is this workflow in line with the way flexibility was intended? Any ideas welcome. Thanks -Venky #vnet -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20058): https://lists.fd.io/g/vpp-dev/message/20058 Mute This Topic: https://lists.fd.io/mt/85304201/21656 Mute #vnet:https://lists.fd.io/g/vpp-dev/mutehashtag/vnet Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
