From: Neale Ranns <ne...@graphiant.com> Sent: Saturday, April 17, 2021 8:57 AM To: hem...@mnkcg.com; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] dst mac-address look up?
From: hem...@mnkcg.com <mailto:hem...@mnkcg.com> <hem...@mnkcg.com <mailto:hem...@mnkcg.com> > Date: Friday, 16 April 2021 at 21:07 To: 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? [Then you're also missing the source mac and the vlan tags. Retrieving these from the local interface and finding the ip-neighbor per-packet in the data-path is a considerable cost - the information is distributed across various memory locations, stored in tables that are not optimised. You should instead build in the control plane an address+interface lookup table and link the result to the appropriate adjacency.] Regarding "missing the source mac and the vlan tags." Why not use u32 adj_index = vnet_buffer (b)->ip.adj_index[VLIB_TX]; ip_adjacency_t *adj = adj_get(adj_index); to get rewrite string and egress encap. The control plane table you speak of uses a key which is already defined as ip_neighbor_key_t. So, why not lookup the ip_neighbor table? Once the ip_neighbor_t entry is available, use ip_neighbor_get_mac() to get destination mac to forward the packet. It's not needed, but ip_neighbor_t does include a ipn_fib_entry_index for any fib/adj tie up to ip-neighbor. Hemant
smime.p7s
Description: S/MIME cryptographic signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19239): https://lists.fd.io/g/vpp-dev/message/19239 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] -=-=-=-=-=-=-=-=-=-=-=-
