On Wed, Feb 01, 2012 at 03:32:26PM -0800, Roland Dreier wrote: > > Would making the allocation of the neigh structure returned by > > dst_lookup_neigh() large enough to hold the ARP/ND HW addr and also > > the IB path record solve these problems? At least for UD? > > I don't think so, because we don't always have a neighbour when > we get a packet to send (eg unicast ARP), and we need a place to > queue up packets while we do the path lookup (the ipoib_neigh.queue > list does that now). So we definitely need paths/AHs separate from > neighs for the first part and we need more than just data in the neigh > for the second part.
I guess I'm missing something. I thought the stack didn't have a unicast hwaddr separate from a neighbour structure? Isn't that where it is stored? Unicast arp does have a destination IP address and a destination hwaddr... To elaborate a bit more what was idly in my head, if the new approach is to always lookup the neighbor on demand, and that can include an ARP to the network, then can't we piggyback on that same process to issue a path record? With a 1:1 correspondence between unicast neighbour, path record, and AH they can all be stored in the same allocation, with the same lifetime. Thus you don't need the second part, and maybe the first part becomes an inefficient special case? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
