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 <ne...@graphiant.com> 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 <vpp-dev@lists.fd.io> on behalf of Venky > Venkatesh via lists.fd.io <vvenkatesh=paloaltonetworks....@lists.fd.io> > *Date: *Wednesday, 1 September 2021 at 16:48 > *To: *vpp-dev@lists.fd.io <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_&d=DwMF-g&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=w2W5SR0mU5u5mz008DZNCsexDN1Lr9bpL7ZGKuD0Zd4&m=bdaAaiMxrwSAEn2IzzNT7qwU8Iy_G-G-eQlabvZRaDM&s=zLAgC1KZL_0sC1trbkMPHqZrVJHEWT5__qCEOOVPJ1U&e=>. > 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] -=-=-=-=-=-=-=-=-=-=-=-
