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. 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: https://gerrit.fd.io/r/c/vpp/+/32023/1 Thanks, Hemant
smime.p7s
Description: S/MIME cryptographic signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19241): https://lists.fd.io/g/vpp-dev/message/19241 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] -=-=-=-=-=-=-=-=-=-=-=-
