On Mon, Feb 6, 2012 at 11:12 AM, David Miller <da...@davemloft.net> wrote: >> 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. > > An address is not a hardware MAC header, we're only talking > about the length of the latter. > > If the addressing is such that you need to put the GID > into the ARP/NDISC packets, and that's different from what > ends up in the final encapsulation header, I really don't > see what the problem is specificially with respect to the > MAC header size.
Dave, please look at my whole email. The problem is that the LL addr is not what we need to send packets but it's all we get in our .hard_header method. So for eg unicast ARP packets without a dst we have nowhere to stash what we actually will need in our xmit method. (The same problem for unicast ARPs applies to multicast sends too). Does the netdev driver own skb->cb between hard_header and start_xmit? If so we could use that instead of stealing some header space, and that would at least let us not lie about hard_header_len. - R. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
