|
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
|
