Hello, ok ok, so it matches my understanding. I was afraid you have problems with HW csum disabled. I understand all this, that is the reason for my patch. That is my doubt too. iptunnel_handle_offlo
Hey The driver in question is mlx4_en version 2.2-1 In this case, we have MLX4_TUNNEL_OFFLOAD_MODE turned off, so hw_enc_features is set to 0. We run into problems with packets captured from NF_INET_
Hello, For the case with missing NETIF_F_ALL_CSUM bits skb_checksum_help() does not care for skb->encapsulation, it works only by checking skb->csum_* fields. The skb_set_inner_transport_header() and
Hey, So I've found a patch that addresses the problem in what I suspect is the right way. diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c index 6f70bdd..ea7ef5e 100644
Hello, I just saw that changing skb->transport_header before skb_reset_inner_headers() and iptunnel_handle_offloads() can cause problems. Not sure if skb->transport_header is used later when skb->enc
Hello, There is skb_checksum_help() call in dev_hard_start_xmit(), it is used when TCP/UDP offload is not supported. After checking the code I see only the CHECKSUM_PARTIAL + Enabled TCP/UDP CSum as
Thank you for the review! 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
Hello, 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_summ
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