Le jeudi 02 février 2012 à 16:01 +0200, Or Gerlitz a écrit : > 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?
I guess changing hard_header_len might be difficult (for you). Adding gro_mac_header_len sounds the easy way. [ You'll need to set it in your device setup() ] -- 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
