On Wed, Feb 1, 2012 at 2:26 PM, Jason Gunthorpe <[email protected]> wrote: > I thought a big reason the IPoIB stuff was setup this way was to fit > in with older kernels (eg we cannot change the neigh structures)?
No, IPoIB tries to be as "native" as possible. The problem as I see it is that IPoIB does standard ARP/ND, but then it has an extra step (path record lookup) to turn that neighbour into an address handle we can use to actually send a packet. And the networking stack doesn't really have a good place to add that extra step -- we can override the neighbour discovery / ARP layer, but we can't tack on another step. > 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. - R. -- 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
