From mboxrd@z Thu Jan 1 00:00:00 1970 From: Davide Caratti Date: Tue, 28 Feb 2017 10:31:11 +0000 Subject: Re: [RFC PATCH net-next 2/5] net: split skb_checksum_help Message-Id: <1488277871.3248.34.camel@redhat.com> List-Id: References: <532e1db70b6c40f1b1e5c60b5b51be9f3437a30b.1485177252.git.dcaratti@redhat.com> <063D6719AE5E284EB5DD2968C1650D6DB026CEA4@AcuExch.aculab.com> <1486048043.2556.4.camel@redhat.com> <1488202783.2713.67.camel@redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Tom Herbert Cc: David Laight , "David S. Miller" , Linux Kernel Network Developers , "linux-sctp@vger.kernel.org" , Marcelo Ricardo Leitner On Mon, 2017-02-27 at 07:11 -0800, Tom Herbert wrote: > CHECKSUM_PARTIAL is the preferred mechanism on the transmit path this > defers defers the checksum computation as long as possible. > Unfortunately, if SCTP is encapsulated in UDP we will probably need to > run the SCTP CRC on the host which will be done with your changes to > skb_checksum_help. right. Tunnel devices have NETIF_F_SCTP_CRC bit cleared and NETIF_F_HW_CSUM bit set: so, in this case csum_not_inet can help recovering non-GSO SCTP packets having ip_summed equal to CHECKSUM_PARTIAL. > > I'm not sure if setting CHECKSUM_UNNECESSARY fits my case, because this= would > > implicitly skip RX validation when using devices like veth or loopback. > > > CHECKSUM_UNNECESSARY can be used in the transmit path (really the > forwarding path), however this I think this must imply that the > checksum in the packet must be correct. Please see my post about > drivers that are mistakingly using CHECKSUM_UNNECESSARY with LRO since > the checksum in the packet sent into the stack is not correct. Ok, now I'm more convinced to use CHECKSUM_NONE :-) thank you for the attention! regards -- davide =C2=A0