Thank you for the review! > > Hello, > > On Tue, 22 Jul 2014, Alex Gartrell wrote: > > > The combination of NF_INET_LOCAL_OUT and hardware checksum offload > > results in picking the packet out of the send path before it gets > > proper checksums. Our NICs (most NICs?) cannot do the checksumming > > in ipip packets, so these faulty tcp/udp headers arrive at their > > destination and are discarded. > > > > Instead, checksum the tcp/udp packets in the tunnel transmit path. > > Right now we do this for all packets, but a subsequent patch will > > limit this to the NF_INET_LOCAL_OUT hook. > > After the support for hardware-offloaded encapsulation > went in we may lack some support, like playing with > skb->encapsulation, etc. I'm not sure calculating the checksums in all > cases (ip_summed) is the right thing to do. > > For DR and TUN we tried to avoid checking and > calculating checksum because we do not mangle the payload. > But CHECKSUM_PARTIAL in ip_summed is a special case. > We call skb_forward_csum() from ip_vs_tunnel_xmit_prepare > but may be it is not enough. Such interesting case is > local TCP client (CHECKSUM_PARTIAL) forwarded via TUN. Yes, it appears that skb_checksum_help was the magic function I was hoping for. I'll put up a new patch that invokes this function, as it seems to fix the problem by itself (and by checking the ip_summed field, it . > Can you give more information, eg. what > value you see in ip_summed, leading to these problems? > And whether packet to IPVS comes from local stack or > from remote client. Is TCP/UDP checksum offload running? > Three tests: * From a remote server: CHECKSUM_UNNECESSARY * From the local server with hardware checksum offload enabled: CHECKSUM_PARTIAL * From the local server with hardware checksum offload disabled: CHECKSUM_PARTIAL I was mildly surprised by the last one. In general I think that ip_summed is a better way to figure out whether or not we should checksum though. In any event, given that the skb_checksum_helper function is way more likely to "just work," I'll put out a patch that adds this invocation instead. Thanks, Alex-- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
