Re: Checksum offload queries

On Sat, Dec 12, 2015 at 8:41 AM, Sowmini Varadhan wrote: > On (12/11/15 15:50), Tom Herbert wrote: >> layers of encapsulation. For example, suppose send a UDP packet in >> VXLAN in VXLAN, where packet looks like: >> IP|UDP|VXLAN|Eth|IP|UDP|VXLAN|Eth|IP|UDP. I believe

Re: Checksum offload queries

On (12/11/15 15:50), Tom Herbert wrote: > layers of encapsulation. For example, suppose send a UDP packet in > VXLAN in VXLAN, where packet looks like: > IP|UDP|VXLAN|Eth|IP|UDP|VXLAN|Eth|IP|UDP. I believe the kernel can set Without detracting from the fact that you have probably found a bug for

Re: Checksum offload queries

>> If your device is trying do offload more than one checksum on its own > >> accord without being asked to do so by the stack it is doing the > wrong >> thing! > From the stack's perspective: yes, it is doing the wrong thing. (I've > been discussing with colleagues today how we could change

Re: Checksum offload queries

Edward Cree wrote: > I have just realised something startling. Assuming the inner protocol uses > the ones complement checksum in the way IP, UDP and TCP do, the outer > checksum can be computed *without looking at the payload*. Why? Because the > ones complement sum

Re: Checksum offload queries

On 10/12/15 16:26, Tom Herbert wrote: > It sounds like potentially interesting work. You'll probably want my patches > that provider helper functions that allow a driver to verify that it can > offload a checksum. We'll have to update those also to allow two checksums. I have just realised

Re: Checksum offload queries

On 09/12/15 18:00, Tom Herbert wrote: > That is not at all true. If the stack has set up VXLAN RCO and the > device > decides to set the inner checksum itself then the checksum > will be bad. The > checksum interface is very specific please read it > carefully (sk_buff.h), > if the

Re: Checksum offload queries

On Thu, Dec 10, 2015 at 7:49 AM, Edward Cree wrote: > On 09/12/15 18:00, Tom Herbert wrote: >> That is not at all true. If the stack has set up VXLAN RCO and the > device >> decides to set the inner checksum itself then the checksum > will be bad. >> The checksum interface

Re: Checksum offload queries

On 08/12/15 17:06, David Miller wrote: > All of the headers get touched anyways as each layer of the stack > demuxes > the packet. Therefore there is _ZERO_ cost to use 1's > complement to > validate checksums in input. It's always superior. Ah, I understand now, it's touching the memory that's

Re: Checksum offload queries

On Wed, Dec 9, 2015 at 4:14 AM, Edward Cree wrote: > On 08/12/15 17:06, David Miller wrote: >> All of the headers get touched anyways as each layer of the stack > demuxes >> the packet. Therefore there is _ZERO_ cost to use 1's > complement to >> validate checksums in

Re: Checksum offload queries

On Tue, Dec 8, 2015 at 5:56 PM, Thomas Graf wrote: > On 12/08/15 at 09:04am, Tom Herbert wrote: >> There are other reasons why CHECKSUM_COMPLETE is preferable: >> >> - CHECKSUM_COMPLETE is more robust. We have no way to validate that >> the device is actually correct in

Re: Checksum offload queries

On 09/12/15 16:01, Tom Herbert wrote: > On Wed, Dec 9, 2015 at 4:14 AM, Edward Cree > wrote: > >> Convincing hardware designers to go the HW_CSUM way and only fill >> in > the inner checksum, when their current approach can fill in >> both inner and > outer checksums

Re: Checksum offload queries

On Wed, Dec 9, 2015 at 9:28 AM, Edward Cree wrote: > On 09/12/15 16:01, Tom Herbert wrote: >> On Wed, Dec 9, 2015 at 4:14 AM, Edward Cree > wrote: >> >> Convincing hardware designers to go the HW_CSUM way and only fill >> in >> the inner checksum,

Re: Checksum offload queries

On 12/09/15 at 08:08am, Tom Herbert wrote: > On Tue, Dec 8, 2015 at 5:56 PM, Thomas Graf wrote: > > If I understood Edward correctly, his proposal would be for the > > card to provide both, the csum as for CHECKSUM_COMPLETE plus the > > validation yes/no hint. It would be up to the

Re: Checksum offload queries

On Wed, Dec 9, 2015 at 2:21 PM, Thomas Graf wrote: > On 12/09/15 at 10:00am, Tom Herbert wrote: >> On Wed, Dec 9, 2015 at 9:28 AM, Edward Cree wrote: >> > Which only pushes the problem onto when someone wants to nest >> > encapsulations. (I heard you like

Re: Checksum offload queries

On 12/09/15 at 02:42pm, Tom Herbert wrote: > csum_start and csum_offset together occupy 32 bits. As demonstrated in > VXLAN RCO we can compress csum_start/csum_offset down to 8 bits which > means if necessary we could get up to four pairs in an sk_buff without > increasing its size. If you need

Re: Checksum offload queries

On 12/09/15 at 10:00am, Tom Herbert wrote: > On Wed, Dec 9, 2015 at 9:28 AM, Edward Cree wrote: > > Which only pushes the problem onto when someone wants to nest > > encapsulations. (I heard you like tunnels, so I put a tunnel in your > > tunnel so you can encapsulate while

Re: Checksum offload queries

On 12/09/15 at 02:51pm, Tom Herbert wrote: > I'm sorry, I still don't understand your point. What is "automatic > nested checksum filling" and how does this relate to RX (e.g. > CHECSUM_COMPLETE). Too much compression ;-) My understanding of the thread was that the desired state is no checksum

Re: Checksum offload queries

On Wed, Dec 9, 2015 at 2:29 PM, Thomas Graf wrote: > On 12/09/15 at 08:08am, Tom Herbert wrote: >> On Tue, Dec 8, 2015 at 5:56 PM, Thomas Graf wrote: >> > If I understood Edward correctly, his proposal would be for the >> > card to provide both, the csum as for

RE: Checksum offload queries

From: Edward Cree > Sent: 09 December 2015 17:29 You also need to stop (probably outluck?) from deleting newlines and flowing the text. The message below is completely unreadable. David > On 09/12/15 16:01, Tom Herbert wrote: > > On Wed, Dec 9, 2015 at 4:14 AM, Edward Cree

Re: Checksum offload queries

On 07/12/15 19:38, David Miller wrote: > No, it is better to universally provide the 1's complement sum for > all receive packets. This allows the stack more flexibility in > checksum handling. I'm afraid I still don't see it. If a device can both provide the 1's complement sum _and_ validate

Re: Checksum offload queries

On Tue, Dec 8, 2015 at 8:03 AM, Edward Cree wrote: > On 07/12/15 17:29, Tom Herbert wrote: >> On Mon, Dec 7, 2015 at 7:39 AM, Edward Cree wrote: >>> 2) Transmit checksums. >> It's analogous to CHECKSUM_COMPLETE, NETIF_F_HW_CSUM works for all >> cases

Re: Checksum offload queries

On 07/12/15 17:29, Tom Herbert wrote: > On Mon, Dec 7, 2015 at 7:39 AM, Edward Cree wrote: >> 2) Transmit checksums. > It's analogous to CHECKSUM_COMPLETE, NETIF_F_HW_CSUM works for all > cases of checksum offload and any combination of protocol layering. ... until a

Re: Checksum offload queries

From: Edward Cree Date: Tue, 8 Dec 2015 14:42:19 + > I'm afraid I still don't see it. You assume that nothing in the stack mangles the packet and would benefit from having the 1's complement to work with in order to assist with checksum adjustments etc. So we want 1's

Re: Checksum offload queries

From: Edward Cree Date: Tue, 8 Dec 2015 16:03:18 + > NETIF_F_HW_CSUM is limited to one checksum per packet. This is false. As we demux encapsulation layers, we re-adjust the provided 1's complement sum provided and use that to validate the next layer. This works for

Re: Checksum offload queries

On Tue, Dec 8, 2015 at 6:42 AM, Edward Cree wrote: > On 07/12/15 19:38, David Miller wrote: >> No, it is better to universally provide the 1's complement sum for >> all receive packets. This allows the stack more flexibility in >> checksum handling. > I'm afraid I still

Re: Checksum offload queries

On 08/12/15 17:09, David Miller wrote: > From: Edward Cree > Date: Tue, 8 Dec 2015 16:03:18 + > >> NETIF_F_HW_CSUM is limited to one checksum per packet. > This is false. > > As we demux encapsulation layers, we re-adjust the provided 1's > complement sum provided and

Re: Checksum offload queries

From: Edward Cree Date: Tue, 8 Dec 2015 17:24:55 + > The context here was transmit, not receive; the stack muxes > encapsulation layers and then asks the hardware to fill in one > checksum, it doesn't have any way to fill in 'adjusted' checksums in > other layers. The

Re: Checksum offload queries

On 08/12/15 16:43, Tom Herbert wrote: > On Tue, Dec 8, 2015 at 8:03 AM, Edward Cree wrote: >> On 07/12/15 17:29, Tom Herbert wrote: >>> On Mon, Dec 7, 2015 at 7:39 AM, Edward Cree wrote: 2) Transmit checksums. >>> It's analogous to

Re: Checksum offload queries

On 12/08/15 at 09:04am, Tom Herbert wrote: > There are other reasons why CHECKSUM_COMPLETE is preferable: > > - CHECKSUM_COMPLETE is more robust. We have no way to validate that > the device is actually correct in CHECKSUM_UNNECESSARY. For instance, > how do we know that there isn't some failure

Re: Checksum offload queries

On Mon, Dec 7, 2015 at 7:39 AM, Edward Cree wrote: > Having decided to take Dave Miller's advice to push our hardware guys in the > direction of generic checksum offload, I found I wasn't quite sure exactly > what's being encouraged. After discussing the subject with a

Re: Checksum offload queries

From: Edward Cree Date: Mon, 7 Dec 2015 15:39:52 + > 1) Receive checksums. Given that CHECKSUM_UNNECESSARY conversion > exists (and is a cheap operation), what is the advantage to the > stack of using CHECKSUM_COMPLETE if the packet happens to be a > protocol which

Re: Checksum offload queries

On Mon, Dec 7, 2015 at 9:29 AM, Tom Herbert wrote: > On Mon, Dec 7, 2015 at 7:39 AM, Edward Cree wrote: >> Having decided to take Dave Miller's advice to push our hardware guys in the >> direction of generic checksum offload, I found I wasn't quite