From: hem...@mnkcg.com <hem...@mnkcg.com> Date: Sunday, 18 April 2021 at 19:25 To: Neale Ranns <ne...@graphiant.com>, vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> Subject: RE: [vpp-dev] dst mac-address look up? I test using a plugin_test.py script.
I am using device-input to ingress packets. The packets undergo a 6-tuple lookup (simplified description of the plugin) after which the packets are egressed using interface-output node. The adjacency is not complete when the packet is ready to be shipped out the egress interface. In regards to using “u32 adj_index = vnet_buffer (b)->ip.adj_index[VLIB_TX];” when an interface is initialized, the interface rewrite adjacency is setup with zero dst mac since dst mac is not known – see vnet_build_rewrite_for_sw_interface(). I have no other means to find a completed adjacency for first packet to a dst. So I have to search the ARP/ND table using dst IP+interface, get a neighbor, and then I can complete the adjacency for subsequent packets to dst IP. My plugin could maintain a client adj bihash database to lookup (key=dst IP) subsequent packets adj->rewrite_header – this is way I avoid looking up the ip-neighbor table for other packets which are not the first packet to a dst. If the adjacency is incomplete, then there is no ip_neghbor. It’s the ip_neighbor that provides the dst mac that completes the adjacency. Think of the adjacency as the cache in the data-plane of all the data that the control-plane provides to forward a packet to a given neighbour (src,dst mac, vlan tags and ether-type). You can’t forward to that neighbour until we have the dst mac, so one of the reasons we have incomplete adjacencies is so that when packets need to be forwarded to a neighbour whose dst mac is not yet known we generate rate-limited ARP/ND requests. So I would advise that the result of your 6-tuple lookup is the adjacency, then you can send the packets to ip4-arp-inline, if it’s incomplete, or ip4-rewrite if it is complete. Using the ipX node, rather than interface-output, means you get ttl decrement plus checksum update, fragmentation and features (ACL, NAT etc). Uou might find the example of the ABF plugin useful as an example of building lookup tables that resolve through adjacencies (or any other fib like path). Regarding scale of ip_neighbor db, I see 50k clients are supported. This would work for me. If higher scale is needed, we could change the ip-neighbor db to use VPP bihash. In summary, if I use ip-neighbor lookup only for first packet to a destination, it would be good to support a new API to find_entry. See update code changes here: The nieghbour DB is arranged per-interface so that it is efficient to walk. So when interface x goes down and we need to walk all of its neighbours to flush them )of which there could be few), we don’t need to walk the entire neighbour table (of which there could be many). /neale https://gerrit.fd.io/r/c/vpp/+/32023/1 Thanks, Hemant
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19243): https://lists.fd.io/g/vpp-dev/message/19243 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] -=-=-=-=-=-=-=-=-=-=-=-
