> > > > > Out of curiosity - what does RDMA NIC have that would need these events? > > > a route table or L2 table etc? Can you elucidate a little? > > > > > > > Mainly the L2 table, next hop ip addr, and the path mtu. RDMA NICs > > implement the entire RDMA stack in HW. How they deal with L2 and L3 > > changes vary to some degree, but what seems to be emerging is that they > > get this information from the native stack because ARP and ICMP, for > > example, are always passed up to the native stack. > > > > I am still unclear: > You have destination IP address, the dstMAC of the nexthop to get the > packet to this IP address and i suspect some srcMAC address you will use > sending out as well as the pathMTU to get there correct? > Because of the IP address it sounds to me like you are populating an L3 > table
I mispoke. The HW I'm using really only maintains a table of next hop mac addrs and a table of src mac addrs. Each active RDMA connection in HW keeps an index into each table for building the ethernet header. The _driver_ needs to know when the next hop mac addr changes, or when the next hop itself changes for a given destination so that it can update the active connections and/or the L2T table accordingly. Same deal with the path mtu... > How is this info used in hardware? Can you explain how an arriving > packet would be used by the RDMA in conjunction with this info once it > is in the hardware? > I think my stuff above explains this, eh? > > These devices also act a standard Ethernet NIC btw... > > > > Meaning there is no funky hardware processing? > If an incoming packet is not for one of the active RDMA connections (or a listening RDMA endpoint), then the packet is passed up to the native stack via the device's netdev driver. Stevo. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
