netdev - Re: [PATCH v5 net-next 01/36] net: Introduce direct data placement tcp offload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 22 Jul 2021 15:39:57 +0200
From:   Eric Dumazet <edumazet@...gle.com>
To:     Boris Pismenny <borispismenny@...il.com>
Cc:     Boris Pismenny <borisp@...dia.com>,
        David Ahern <dsahern@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>,
        Saeed Mahameed <saeedm@...dia.com>,
        Christoph Hellwig <hch@....de>, sagi@...mberg.me, axboe@...com,
        kbusch@...nel.org, Al Viro <viro@...iv.linux.org.uk>,
        smalin@...vell.com, boris.pismenny@...il.com,
        linux-nvme@...ts.infradead.org, netdev <netdev@...r.kernel.org>,
        benishay@...dia.com, ogerlitz@...dia.com, yorayz@...dia.com,
        Boris Pismenny <borisp@...lanox.com>,
        Ben Ben-Ishay <benishay@...lanox.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Yoray Zack <yorayz@...lanox.com>
Subject: Re: [PATCH v5 net-next 01/36] net: Introduce direct data placement
 tcp offload

On Thu, Jul 22, 2021 at 3:33 PM Boris Pismenny <borispismenny@...il.com> wrote:

> Sorry. My response above was about skb_condense which I've confused with
> tcp_collapse.
>
> In tcp_collapse, we could allow the copy, but the problem is CRC, which
> like TLS's skb->decrypted marks that the data passed the digest
> validation in the NIC. If we allow collapsing SKBs with mixed marks, we
> will need to force software copy+crc verification. As TCP collapse is
> indeed rare and the offload is opportunistic in nature, we can make this
> change and submit another version, but I'm confused; why was it OK for
> TLS, while it is not OK for DDP+CRC?
>

Ah.... I guess I was focused on the DDP part, while all your changes
are really about the CRC part.

Perhaps having an accessor to express the CRC status (and not be
confused by the DDP part)
 could help the intent of the code.