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 <ec...@solarflare.com> > 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 (though admittedly only for the
> >> protocols the
> hardware knows about), might be difficult. >> > But again,
> NETIF_F_IP[V6]_CSUM and NETIF_F_HW_CSUM
> describe > capabilities._not_ the interface. The interface currently allows
> only > one checksum to be
> offloaded at time, if we want to be able to > offload two checksums then the
> interface needs to be
> changed-- > probably something like defining a new capability like >
> NETIF_F_HW_2CSUMS, adding another
> csum_start,csum_offset pair into > the sk_buff.
> 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?
>
> > The stack will need to be modified also wherever CHECKSUM_PARTIAL is >
> > handled.
> Naturally.
>
> > 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 that, and I
> think we can, but it involves having _three_ hardware TXQs per kernel
> queue, instead of the two we have now...)
> But from the outside perspective, the system as a whole isn't doing
> anything bad - the packet going on the network is valid and just
> happens to have both inner and outer checksums filled in. Is there a
> good reason _why_ the stack forbids a device to do this? (Sure, it's
> not necessary, and makes the hardware more complex. But the hardware's
> already been made, and it's not a *completely* useless thing to do...)
>
> > Please stop adding this disclaimer to your messages, it is not >
> > appropriate for the list.
> Actually, the copy that goes the list doesn't have the disclaimer. But
> thanks to a combination of crappy email server and corporate politics,
> it still sticks it on any CCs. If it were up to me (it's not) we
> wouldn't add that disclaimer to anything ever.
> I'm now attempting (for the nth time) to convince our mgmt to get rid
> of the disclaimer, but I don't hold out much hope :(
> --
> 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
