[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5693E6F8.7040806@solarflare.com>
Date: Mon, 11 Jan 2016 17:31:36 +0000
From: Edward Cree <ecree@...arflare.com>
To: Alexander Duyck <alexander.duyck@...il.com>
CC: Tom Herbert <tom@...bertland.com>,
David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>,
<linux-net-drivers@...arflare.com>
Subject: Re: [PATCH net-next 7/8] net: ip_tunnel: remove 'csum_help' argument
to iptunnel_handle_offloads
On 11/01/16 16:39, Alexander Duyck wrote:
> Your first patch is probably the best place for it. Then when you
> start setting false it doesn't introduce any errors.
Will do.
> Also I was doing a bit more work on the lco_csum function and think I
> have come up with something a bit more elegant[...] What I will do is
> email you the full patch and the GSO patch I have as RFCs to look over
> and possibly incorporate into your own.
<snip>
> +static inline __wsum lco_csum(struct sk_buff *skb)
> +{
> + unsigned char *csum_start = skb_checksum_start(skb);
> + unsigned char *l4_hdr = skb_transport_header(skb);
> + __wsum partial;
> +
> + partial = ~csum_unfold(*(__force __sum16 *)(csum_start +
> + skb->csum_offset));
> + return csum_partial(l4_hdr, csum_start - l4_hdr, partial);
> +}
> +
Looks OK to me. I'd rather tack both of your patches onto the endof the
series, rather than incorporating your patch [1/2] directly into my patch
[1/8]; that way (a) the history allows to understand regular LCO before
adding in the GSO flavour, (b) you're credited for your improved lco_csum.
As for your patch [2/2], I don't pretend to understand GSO right now but it
looks plausible enough. Perhaps you could add a document about GSO to go
alongside the checksum-offloads.txt one?
What testing haveyou done on your series? When rebasing it I'll focus on
the tunnel types you haven't already tested.
-ed
Powered by blists - more mailing lists