Re: [PATCH net-next V2] gro: introduce gro_mac_header_len

On Mon, Feb 6, 2012 at 11:12 AM, David Miller [off-list ref] wrote:

quoted

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html