On 08/12/15 16:43, Tom Herbert wrote:
> On Tue, Dec 8, 2015 at 8:03 AM, Edward Cree <ec...@solarflare.com> wrote:
>> On 07/12/15 17:29, Tom Herbert wrote:
>>> On Mon, Dec 7, 2015 at 7:39 AM, Edward Cree <ec...@solarflare.com> 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 protocol combination comes along that doesn't allow all but the
>> innermost checksum to be 0. NETIF_F_HW_CSUM is limited to one checksum per
>> packet.
> So is NETIF_F_IP[V6]_CSUM, again the interface into the driver to
> offload a checksum is csum_start, csum_offset.
Well, we don't use those values, and I'd be surprised if other
NETIF_F_IP[V6]_CSUM drivers did. The reason why our hardware is restricted to
checksumming IP, rather than being able to checksum everything, is that it
works out the start and offset itself (and only knows how to do that for IP).
Our transmit descriptors don't include csum_start and csum_offset. That may
mean we're Doing It Wrong, but I don't see why anyone Doing It Right would need
to be NETIF_F_IP[V6]_CSUM in the first place, rather than NETIF_F_HW_CSUM.
> Only one checksum can
> be offloaded at a time. We have no way to tell the driver that there
> are two checksums in a packet to be offloaded.
But again, hardware that figures it out for itself doesn't _need_ to be told.
For instance, for a VXLAN-encapsulated TCP packet, our new chip can fill in the
IP header checksum, the (outer) UDP checksum, and the (inner) TCP checksum.
(Our previous chip would do the first two, but not the inner checksum.) I had
assumed that NETIF_F_IP_CSUM included IP header checksum offload; now I'm
wondering if the stack is already filling that in and our hardware is
overwriting it with the same value. From a quick look at our driver, it looks
like that is indeed happening; I guess I should fix that.
--
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
