On 2/1/2012 4:07 PM, Eric Dumazet wrote:
If we just turn it into a memcmp with a variable length would
that work for you?
I think yes, FWIW we will compare the IPoIB header, Roland is that okay for you?
A memcmp(xxx, yyy, variable_len) will be out of line and slow, its a bit sad
... Are skb_mac_header(p) / skb_gro_mac_header(skb) going to point to IPoIB
header ?
yes, both skb_mac_header(p) / skb_gro_mac_header(skb) point to IPoIB
header, however (see next)
Maybe we can keep a fastpath for ethernet case... (the "if (hlen == ETH_HLEN)
being always predicted)
Maybe need to introduce gro_hard_header_len as well)
today, IPoIB advertizes hard_header_len which is bigger than the IPoIB
header len, this is done such that skbs sent by the network stack have
enough headroom for a "pseudoheader" which for few flows (e.g unicast
arp replies and multicast) is placed there by the ipoib hard_header
function and later used by the xmit function.
So we can either try and change that, such that hard_header_len will be
equal to the ipoib header len or add gro_hard_header_len as you
suggested, any preferences?
Or.
Or.
diff --git a/net/core/dev.c b/net/core/dev.c
index 115dee1..62abee4 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3500,14 +3500,20 @@ static inline gro_result_t
__napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
struct sk_buff *p;
+ unsigned int hlen = skb->dev->hard_header_len;
for (p = napi->gro_list; p; p = p->next) {
unsigned long diffs;
diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;
diffs |= p->vlan_tci ^ skb->vlan_tci;
- diffs |= compare_ether_header(skb_mac_header(p),
- skb_gro_mac_header(skb));
+ if (hlen == ETH_HLEN)
+ diffs |= compare_ether_header(skb_mac_header(p),
+ skb_gro_mac_header(skb));
+ else if (!diffs)
+ diffs = memcmp(skb_mac_header(p),
+ skb_gro_mac_header(skb),
+ skb->dev->hard_header_len);
NAPI_GRO_CB(p)->same_flow = !diffs;
NAPI_GRO_CB(p)->flush = 0;
}
--
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
