_copy_to_iter в perf top

Очень похоже на это.
Копирование между ядром и юзерспейс очень дорогое.
Для борьбы с этим сделали ZeroCopy (для отправки данных через сокеты), mmap для сокета af_packet, а вот для чтения я что-то не припоминаю похожих механизмов.

Не уверен, что io_uring сильно поможет.

Я знаю только 1 способ уменьшения стоимости такого копирования - ядро должно копировать данные в область памяти которая доступна процессу через mmap.

Если читаемые данные не нужно обрабатывать, то их можно копировать в /dev/zero внутри ядра

ИИшница подсказывает

#define _GNU_SOURCE
#include <fcntl.h>
#include <unistd.h>

void fast_flush_tcp(int socket_fd) {
    int null_fd = open("/dev/null", O_WRONLY);
    if (null_fd < 0) return;

    // Splice transfers data cleanly between descriptors entirely within the kernel
    while (splice(socket_fd, NULL, null_fd, NULL, 65536, SPLICE_F_NONBLOCK) > 0) {
        // Kept looping until the source buffer is empty
    }

    close(null_fd);
}

данные конечно нужны.

А почему io_uring может не подойти на чтение? Это же как раз тот случай вроде бы.

io_uring - это способ асинхронно вызвать syscall и получить результат.
IMHO Если syscall будет пересылать данные в userspace, то накладные расходы на копирование из ядра никуда не денутся.
Я бы попробовал следующее: в клиенте выделить память для чтение данных через mmap и читать данные в такой буфер.

ИИшница подсказывает, что еще нужно выполнить

#include <netinet/tcp.h>

struct tcp_zerocopy_receive zc = {0};
zc.address = (__u64)addr; // The memory address obtained from mmap
zc.length = map_size;     // Size of the mapping region

// This system call maps the physical pages and tracks how much was mapped
int res = getsockopt(sock_fd, SOL_TCP, TCP_ZEROCOPY_RECEIVE, &zc, sizeof(zc));
madvise(addr, zc.length, MADV_DONTNEED);

Спасибо, попробую ваш метод тоже.

Если это раздача файликов, то почему не sendfile?

Т.е. переход на io_uring может помочь?

Нет, потому что он нужен не для уменьшения копирований, а для уменьшения context switch.

sendfile, ksplice - всё это в обязательном режиме безусловно требует ktls, сегодня не бывает нешифрованного трафика.

Но я говорю про лайв и тем более речь шла про прием. Сейчас ставлю эксперимент: залить на сторадж с 38 дисками максимум, что они вывезут.

У каждого по 2 гигабита записи, т.е. 38*1.7 = 60 гигабит входа. Надо попыхтеть.

занимается перекопированием из ядра в программу

а iov/srviov включено?

дак как же это так, если ты ему отдаешь свой буфер, в который он как раз пишет или из него читает.

https://docs.kernel.org/networking/iou-zcrx.html

вот же, в интернетах пишут.

https://docs.kernel.org/networking/iou-zcrx.html

Это какая-то отдельная магия, я такого еще не видел. Но если тебе с диска отдавать, то ничего лучше ktls + sendfile наверное нет.

Я переезжаю в нашем видеостриминговом сервере с erlang на rust …

А почему решили отказаться от Эрланга? Причина техническая?

не осилили в девятки

И техническая, и кадровая.

Я задолбался писать велосипеды на эрланге и на выходе получается, что даже 20 гигабит вытянуть - это целое достижение.

я же говорю: с диска это только если устраивать игрища с kernel tls, но мне и не это нужно