On Wed, Dec 9, 2015 at 2:21 PM, Thomas Graf <tg...@suug.ch> wrote: > On 12/09/15 at 10:00am, Tom Herbert wrote: >> On Wed, Dec 9, 2015 at 9:28 AM, Edward Cree <ec...@solarflare.com> 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 you encapsulate.) >> > Or to put it another way, 2 isn't a number; the only numbers are 0, 1 >> > and infinity ;) >> > Perhaps in practice 2 csums would be enough, for now. But isn't the >> > whole point of the brave new world of generic checksums that it should >> > be future-proof? >> > >> If there is a need then we can add an arbitrary number. But no one has >> proven there is a need, however we do have a real need for checksum >> offload outside of the narrow uses of NETIF_F_IP[V6]_CSUM. > > Need may be a strong word here but people have started doing nested > tunneling by running container orchestration tools which use VXLAN > to isolate containers inside of OpenStack virtual infrastructure which > also creates virtual networks. > > I'm not saying it's sane or desirable but we will start seeing nested > tunnels in the wild :-(
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 more that four checksums to be offloaded in single packet then I doubt getting checksum offload to work is going to be your biggest problem. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
