On 12/09/15 at 02:51pm, Tom Herbert wrote: > I'm sorry, I still don't understand your point. What is "automatic > nested checksum filling" and how does this relate to RX (e.g. > CHECSUM_COMPLETE).
Too much compression ;-) My understanding of the thread was that the desired state is no checksum validation on RX and no automatic checksum offload on TX unless explicitly instructed via csum offset. This is what I would call a CHECKSUM_COMPLETE card (no protocol parsing). As opposed to a CHECKSUM_UNNECESSARY card which does protocol parsing. Some do nested checksum offload on TX as we know even if only instructed to do one of the checksums. So let's assume everybody goes CHECKSUM_COMPLETE and we have at most a single level of checksum offload on TX. (As I understand, a requirement to not break RCO anyway.) RCO would resolve the possible software checksum performance bottleneck in the scenario of outer and inner header checksum requirements. While I agree that this is the case, we need to have support in hardware VTEPs for this in order for it to be usable. (excluding those which require a checksum 0 anyway) Multiple nested tunnels would be another beast outside of the scope of RCO but as I stated in the other email, I don't think we should proactively solve that. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
