Hi Hemant, This conversation seems to be going round in circles a bit, so this is my last contribution…
From: hem...@mnkcg.com<mailto:hem...@mnkcg.com> <hem...@mnkcg.com<mailto:hem...@mnkcg.com>> Date: Monday, 19 April 2021 at 17:23 To: hem...@mnkcg.com<mailto:hem...@mnkcg.com> <hem...@mnkcg.com<mailto:hem...@mnkcg.com>>, Neale Ranns <ne...@graphiant.com<mailto:ne...@graphiant.com>>, vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Subject: RE: [vpp-dev] dst mac-address look up? I do see a correct adj in the output from “sh adj” for the pg1 interface. [@16] ipv6 via 2002::2 pg1: mtu:9000 next:4 flags:[] 002590ebe8ed02fee2df6d1386dd So the issue is how I get adj_index in the VPP plugin code is clearly not working. u32 adj_index = vnet_buffer (b)->ip.adj_index[VLIB_TX]; ip_adjacency_t *adj = adj_get(adj_index); [the adjacency is written into the packet metadata as a result of a forwarding decision. Usually this is ip[46]-lookup. As you said your plugin bypasses that, so you need to do your own lookup to get the adj – hence the table I was suggesting.] Ah, I see – it’s the good old layer-3 routing lookup. My plugin has already found the egress interface (via other means). But the layer-2 information to forward the packet is incomplete. On any hardware switch/router when layer-2 information is incomplete, one uses ARP/ND to complete the information. From the output of “show adj”, it’s clear, the adj is a glean-adj from ARP/ND. you gave the output of the adj table: [@16] ipv6 via 2002::2 pg1: mtu:9000 next:4 flags:[] 002590ebe8ed02fee2df6d1386dd so “it’s clear” the adj is complete and the rewrite data is available So, why not use ip-neighbor table to complete the layer-2 information? Using a control-plane table is tricky. What if the VPP node uses 32 virtual switched ports. If a control-plane table is used, how is the result of table lookup provisioned because the user would need to find the mac of next hop for each of the 32 switched ports. What happens when next hop ports change? ARP/ND detect such a change automatically. This gets to the heart of how you design a system optimised for fast forwarding. Rule number 1, everything you can do in the control plane you do in the control plane so that the minimum work needs to be done in the data-plane. This, among other things, is what the adj is for; it is the all the information needed to forward packets to a neighbour all present and always correct on 1 cache line. Any changes that would affect that adj are propagated through the control plane to any parts of the system that are interested. Lookup tables update when these changes happen. So tricky, yes, hard, yes, but it will give you better results. So don’t be lazy 😉 This is why I am saying, my plugin use case should just use the ip-neighbor table which currently does not support a lookup with ip+interface. I am adding such a lookup. Also, such a lookup is supported by ARP/ND code of any hardware router/switch. Your ‘other HW platforms do it this way’ arguments aren’t productive. VPP does it VPP’s way and gives good results. You either work within that framework and reap the performance benefits or you do it your way and pay the performance costs. If you really want to do CP work in the DP, and pay the large performance cost, be my guest. An API that’s ip_neighbour_t * ip_neighbour_find(ip_neighbour_key *k); would not be a bad addition. /neale
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19264): https://lists.fd.io/g/vpp-dev/message/19264 Mute This Topic: https://lists.fd.io/mt/82127329/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
