[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F300353.2080705@mellanox.com>
Date: Mon, 6 Feb 2012 18:44:03 +0200
From: Or Gerlitz <ogerlitz@...lanox.com>
To: David Miller <davem@...emloft.net>
CC: <eric.dumazet@...il.com>, <sean.hefty@...el.com>,
<herbert@...dor.hengli.com.au>, <linux-rdma@...r.kernel.org>,
<shlomop@...lanox.com>, <roland@...nel.org>,
<netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] gro: introduce gro_mac_header_len
On 2/6/2012 6:31 PM, David Miller wrote:
> We really need an explanation, probably both in the commit message and
> the comments next to this new struct member, explaining why in the
> world we can't use ->hard_header_len for this.
Dave,
As I wrote earlier on this thread, the reason is that in order to be
able to xmit skb's for which the stack doesn't provide a neighbour,
IPoIB makes sure to have extra INFINIBAND_ALEN bytes headroom on skbs.
Such that the ipoib hard_header functions writes a "ipoib_pseudoheader"
(= hw address) on the skb and the xmit function grabs it from there and
use that pseudoheader to search for the actual IB L2 address handle kept
for that dest. Example such skbs are unicast ARP replies and multicast.
see below some relevant code sections from ipoib_main.c
Or.
> static void ipoib_setup(struct net_device *dev)
> [...]
> /*
> * We add in INFINIBAND_ALEN to allow for the destination
> * address "pseudoheader" for skbs without neighbour struct.
> */
> dev->hard_header_len = IPOIB_ENCAP_LEN + INFINIBAND_ALEN;
> dev->addr_len = INFINIBAND_ALEN;
> dev->type = ARPHRD_INFINIBAND;
> static int ipoib_hard_header(struct sk_buff *skb,
> struct net_device *dev,
> unsigned short type,
> const void *daddr, const void *saddr,
> unsigned len)
> [...]
> /*
> * If we don't have a neighbour structure, stuff the
> * destination address onto the front of the skb so we can
> * figure out where to send the packet later.
> */
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists