lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <20120206.115859.1384761795375582044.davem@davemloft.net> Date: Mon, 06 Feb 2012 11:58:59 -0500 (EST) From: David Miller <davem@...emloft.net> To: eric.dumazet@...il.com Cc: ogerlitz@...lanox.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, roland@...nel.org Subject: Re: [PATCH net-next V2] gro: introduce gro_mac_header_len From: Eric Dumazet <eric.dumazet@...il.com> Date: Mon, 06 Feb 2012 17:47:14 +0100 [ Roland Dreier CC:'d ] > gro_max_header_len can be different than hard_header_len because as Or > Gerlitz said : > > 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. Translation: IPoIB's path resolution mechanism is garbage So if IPoIB path resolution was properly integrated into the neighbour cache state machine, instead of being implemented awkwardly in the device transmit path, this crap wouldn't be necessary right? So here we have yet another incredibly painful side effect of how IPoIB path resolution works. Roland, I want you to seriously consider a way, any way, to get rid of how IPoIB does path resolution. It must be fully integrated into the neighbour layer, the neighbour layer must be knowledgable about how path resolution is a necessary step for a neighbour entry to enter the valid state, and I want all of this awkward neighbour handling code removed from the transmit path of IPoIB. And finally it must not lie about it's hardware header length. Then we won't need crap like what is being proposed here, a "no_this_is_the_real_hard_header_len" struct member. That's just rediculious. -- 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