On 08/12/2020 2:39, David Ahern wrote: > On 12/7/20 2:06 PM, Boris Pismenny wrote: >> When using direct data placement the NIC writes some of the payload >> directly to the destination buffer, and constructs the SKB such that it >> points to this data. As a result, the skb_copy datagram_iter call will >> attempt to copy data when it is not necessary. >> >> This patch adds a check to avoid this copy, and a static_key to enabled >> it when TCP direct data placement is possible. >> > Why not mark the skb as ZEROCOPY -- an Rx version of the existing > SKBTX_DEV_ZEROCOPY and skb_shared_info->tx_flags? Use that as a generic > way of indicating to the stack what is happening. > >
[Re-sending as the previous one didn't hit the mailing list] Interesting idea. But, unlike SKBTX_DEV_ZEROCOPY this SKB can be inspected/modified by the stack without the need to copy things out. Additionally, the SKB may contain both data that is already placed in its final destination buffer (PDU data) and data that isn't (PDU header); it doesn't matter. Therefore, labeling the entire SKB as zerocopy doesn't convey the desired information. Moreover, skipping copies in the stack to receive zerocopy SKBs will require more invasive changes. Our goal in this approach was to provide the smallest change that enables the desired functionality while preserving the performance of existing flows that do not care for it. An alternative approach, that doesn't affect existing flows at all, which we considered was to make a special version of memcpy_to_page to be used by DDP providers (nvme-tcp). This alternative will require creating corresponding special versions for users of this function such skb_copy_datagram_iter. Thit is more invasive, thus in this patchset we decided to avoid it.
