Of course we need to interoperate with ConnectX-en and it, as far as I know, only knows how to compute the VCRC as though the packet was going to get sent to IB including a phantom 12 byte LRH that is filled with 1's without any way to turn it off. It is also a requirement that UD work well too. Instead of connection setup if we could get a capability bit in a port info record we could handle the general case.
Bob -----Original Message----- From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] Sent: Thursday, December 17, 2009 4:05 PM To: Robert Pearson Cc: 'Roland Dreier'; 'frank zago'; linux-rdma@vger.kernel.org; 'John Groves' Subject: Re: [Announce] rxe dev tree available (soft RDMAoE) On Thu, Dec 17, 2009 at 03:43:56PM -0600, Robert Pearson wrote: > I agree about the polynomial. That would have been nice. As currently > proposed the embedding of the IB transport in Ethernet frames preserves the > IB ICRC as part of the transport and trades the VCRC for Ethernet's CRC32 > over the whole frame. This means that the packet is effectively covered by > CRC32 twice except for the 802 headers and the fields that are excluded from > the ICRC. CRC32C should give better protection. The ICRC isn't even necessary from a technical sense for DCE. The underlying reasons for the ICRC/VCRC split are not really present for ethernet. Considering RDMAoE isn't interoperable with existing IB anyhow and DCE can't do routing, the best course would be to just get rid of it entirely. IMHO, a smart thing would be to figure out how to exchange ICRC capability during the connection setup and turn it off if both sides support it. With the ICRC removed the rxe send side should be able to be completely 0 copy... Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
