On Mon, Feb 6, 2012 at 8:58 AM, David Miller <[email protected]> wrote: > > So if IPoIB path resolution was properly integrated into the neighbour > cache state machine, instead of being implemented awkwardly in the > device transmit path, this crap wouldn't be necessary right? > > So here we have yet another incredibly painful side effect of how > IPoIB path resolution works. > > Roland, I want you to seriously consider a way, any way, to get rid of > how IPoIB does path resolution. It must be fully integrated into the > neighbour layer, the neighbour layer must be knowledgable about how > path resolution is a necessary step for a neighbour entry to enter the > valid state, and I want all of this awkward neighbour handling code > removed from the transmit path of IPoIB. > > And finally it must not lie about it's hardware header length.
I would love to clean this up. But I don't know how to do it. IMHO the problem is in the IPoIB RFC: (4391) which makes a distinction between an "encapsulation header" and the "link layer address". The LL address is what we put into ARP and ND packets, and so I think we are forced into exposing that to the network stack as our hardware address. However this LL address is not actually what we need to send a packet -- we need to take the GID of our destination and send a query to the subnet manager to resolve it to a path. And this query really is an RPC to a remote entity somewhere else on the network, so we have to do it asynchronously etc. Now the part I don't know how to handle is when the network stack gives us a LL address to send an ARP or something to but the skb has no dst attached. Suppose I don't have a path for that LL address when I get that skb with no dst into my .hard_header method. Where do I stick the LL addr to keep around until the packet shows up in the xmit function? - 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
