Re: [PATCH ipvs 1/2] ipvs: Do tcp/udp checksumming prior to tunnel xmit

To: Alex Gartrell <agartrell@xxxxxx>
Subject: Re: [PATCH ipvs 1/2] ipvs: Do tcp/udp checksumming prior to tunnel xmit
Cc: horms@xxxxxxxxxxxx, lvs-devel@xxxxxxxxxxxxxxx, kernel-team@xxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Wed, 23 Jul 2014 11:25:47 +0300 (EEST)

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.

        ipip.c and ip_tunnel_core.c are good source of
information. I think, we can check what is needed
to complete the partial checksum while adding IPIP header.
For example, calling skb_checksum_help() may be
enough for the CHECKSUM_PARTIAL case. See
iptunnel_handle_offloads() for reference.

        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?


Julian Anastasov <ja@xxxxxx>
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

<Prev in Thread] Current Thread [Next in Thread>