|
Hello,
On Fri, 25 Jul 2014, Alex Gartrell wrote:
> 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.
ok
> > Also, can you clarify again which test has
> >the problem with broken csums? All 3 tests? Or it
> >depends on enabled HW csums?
>
> We run into problems with packets captured from NF_INET_LOCAL_OUT when
> we have hardware checksumming enabled. Disabling hardware checksumming
> fixes the problem by removing the bits from the features and makes it
> act roughly the same as just setting the encapsulation bit
ok, so it matches my understanding. I was
afraid you have problems with HW csum disabled.
> >From my reading, the pseudo code for it is basically as follows
>
> Features = device_features # which has a bunch of stuff, including full
> checksumming
>
> If skb->encapsulated:
> Features = device_encapsulated_features # which is zero
>
> If needs_gso(skb, features) # requires that gso params are set and that
> the features have it
> # gso segment stuff
> Else
> If skb->ip_summed == CHECKSUM_PARTIAL: # This is us
> If skb->encapsulation:
> skb_set_inner_transport_header(skb,
> skb_checksum_start_offset(skb))
> Else
> set_transport_header(skb, skb_checksum_start_offset(skb))
> If !(features & NETIF_F_ALL_CSUM): # Basically equal to
> skb->encapsulation for us
> If skb_checksum_help(skb) # will do the software checksumming
> we need
> # do error stuff
I understand all this, that is the reason for
my patch.
> Taking a second look, I think that the problem with my approach is
> that it won¹t take advantage of gso offload for ipip encapsulation.
> Strictly speaking, I don¹t think we need it (the volume of ipvs
> Traffic originating from the host itself is almost always going to
> be negligible). That said, taking advantage is clearly the right
> way to do it.
>
> With that in mind, my only problem with your patch is that ipv4 is
> inconsistent with ipv6. Can we do something like this? (Apologies,
> I¹m stuck with outlook at home and it is ruining the formatting) The
> specific change is that we use the same iptunnel_handle_offloads
> Invocation in ipv4 and ipv6. It¹s disconcerting to me that it¹s unclear
> if we can do IP6IP6 with gso offload ‹ any thoughts there?
That is my doubt too. iptunnel_handle_offloads is
called only for IPv4 tunnels, even in net/ipv6/. OTOH,
ip6_tnl_xmit2() does everything directly, that is why
I choosed the same thing for IPv6. I don't see value to use
instead of SKB_GSO_IPIP. Looking at ipv4_offload_init()
for IPv4 there is offload support for TCP, UDP and IPIP.
ipv6_offload_init() shows support for TCP, UDP,
via ipv6_exthdrs_offload_init for IPPROTO_ROUTING and
IPPROTO_DSTOPTS), sit_offload (IPPROTO_IPV6). So, it
may be possible to use iptunnel_handle_offloads for IPv6.
We may need help from experts in this area. So,
I'll post the patch as RFC on netdev after little
research for GRO/GSO.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
