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  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 <>
To:     Boris Pismenny <>
Cc:     Boris Pismenny <>,
        David Ahern <>,
        Jakub Kicinski <>,
        David Miller <>,
        Saeed Mahameed <>,
        Christoph Hellwig <>,,,, Al Viro <>,,,, netdev <>,,,,
        Boris Pismenny <>,
        Ben Ben-Ishay <>,
        Or Gerlitz <>,
        Yoray Zack <>
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 <> 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.

Powered by blists - more mailing lists