[PATCH net-next RFC v1 03/10] net: Introduce crc offload for tcp ddp ulp
Boris Pismenny
borispismenny at gmail.com
Sun Oct 11 10:58:00 EDT 2020
On 09/10/2020 0:51, Sagi Grimberg wrote:
>> This commit itroduces support for CRC offload to direct data placement
> introduces
>> ULP on the receive side. Both DDP and CRC share a common API to
>> initialize the offload for a TCP socket. But otherwise, both can
>> be executed independently.
> From the API it not clear that the offload engine does crc32c, do you
> see this extended to other crc types in the future?
Yes, it is somewhat implicit, and it depends on the tcp ddp configuration. At the moment we only do nvme-tcp, and that has only CRC32C. If in the future, there would be other CRC variants, or data digest algorithms, then the code could be easily extended.
In general, any data digest over TCP can leverage this code and SKB member. Not only other CRC types can benefit from it, but even more complex data digest algorithms like SHA can use this. In essence this bit is similar to the TLS skb->decrypted bit. In TLS, skb->decrypted also indicates that the authentication has no error, exactly like ddp_crc indicates that there is no CRC32C error. The only reason we didn't use the same bit for both is that these two protocol offloads can be combined and that will benefit from two independent bits.
>
> Other than this the patch looks good to me,
> Reviewed-by: Sagi Grimberg <sagi at grimberg.me>
More information about the Linux-nvme
mailing list