1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/openeuler-gazelle

 / Детали:

[ксдп][ридрис] При повторном тестировании 5000 соединений с большим пакетом set часто наблюдается...

Предстоит сделать
Владелец
Создано  
10.03.2025

увеличение счетчика tx_allocmbuf_fail.

【версия операционной системы】 (например openEuler-22.03-LTS, результат команды "cat /etc/os-release")
openeulerversion=openEuler-22.03-LTS-SP4
compiletime=2025-01-15-15-05-32
gccversion=10.3.1-67.oe2203sp4
kernelversion=5.10.0-246.0.0.145.oe2203sp4
openjdkversion=1.8.0.432.b06-0.oe2203sp4

【версия ядра】 (например kernel-5.10.0-60.138.0.165, результат команды "uname -r")
5.10.0-JD-XDP

【версия программного обеспечения и номер версии】 (например gazelle-1.0.2-83.aarch64, результат команды "rpm -q пакет")
gazelle-1.0.2-83.aarch64
dpdk-21.11-83.aarch64

【инфраструктурная информация】
Двухканальная среда с конфигурацией ipvlan

【шаги воспроизведения проблемы】: Опишите конкретные шаги действий
Запустить redis-server сервер LD_PRELOAD=/usr/lib64/liblstack.so GAZELLE_BIND_PROCNAME=redis-server /root/redis-server ./redis.conf --protected-mode no --bind 124.88.25.225 --save ""

dpdk_args=["--socket-mem", "1024,0,0,0", "--huge-dir", "/mnt/hugepages-lstack", "--proc-type", "primary", "--vdev", "net_af_xdp,iface=ipvlan0,queue_count=1", "-d", "librte_net_af_xdp.so"]

stack_thread_mode="run-to-wakeup"

# режим ltran требует добавления "--map-perfect" и "--legacy-mem" в dpdk_args
use_ltran=0
kni_switch=0
flow_bifurcation=0

low_power_mode=0

# необходимое количество mbuf = tcp_conn_count * mbuf_count_per_conn
tcp_conn_count=1500
mbuf_count_per_conn=238

# размер кольцевой очереди отправки, по умолчанию 32, максимум 2048
# если длина UDP-пакета превышает 45952 (32 * 1436) байт, то значение send_ring_size должно быть как минимум 64.
send_ring_size = 32

# размер кольцевой очереди приема, по умолчанию 128, максимум 2048
recv_ring_size = 128
```# параметры протокола stack thread за один проход
# чтение данных из протокола stack в recv_ring
read_connect_number = 4
# количество обрабатываемых RPC сообщений
rpc_number = 4
# количество прочитанных пакетов NIC
nic_read_number = 128nic_rxqueue_size = 4096
nic_txqueue_size = 2048

# каждый CPU core запускает свой протокол stack thread.
num_cpus="1"

# привязка рабочего потока приложения к NUMA в epoll/poll.
app_bind_numa=1
# установка аффинитет основного потока приложения DPDK.
main_thread_affinity=0

host_addr="124.88.25.225"
mask_addr="255.255.0.0"
gateway_addr="124.88.0.1"
devices="52:54:00:1b:fa:d2"

# 0: использовать правила RSS
# 1: использовать правило TCP-кортежа для направления пакета в очередь NIC
tuple_filter=0

# tuple_filter=1, ниже указаны допустимые параметры
num_process=1
process_numa="0,1"
process_idx=0

# tuple_filter=0, ниже указаны допустимые параметры
listen_shadow=0
```# режим VLAN; поддерживаются значения от -1 до 4094, -1 — отключено
nic_vlan_mode=-1

# режим объединения; поддерживаются режимы объединения OnClickListener 4 и 6, -1 — отключено
bond_mode=-1
# MAC-адреса slaves объединения, разделённые точкой с запятой, поддерживаются два MAC-адреса slaves
# bond_slave_mac="aa:bb:cc:dd:ee:ff;gg:hh:ii:jj:kk:ll"

# максимальное количество пулов памяти RPC
rpc_msg_max=4096
send_cache_mode=1
stack_interrupt=1


  1. Клиент последовательно выполняет
    /root/redis-6.2.9/src/redis-benchmark -h 124.88.25.225 -p 6379 -c 10 -n 1000000000 -d 10800 -t get
    /root/redis-6.2.9/src/redis-benchmark -h 124.88.25.225 -p 6379 -c 10 -n 1000000000 -d 10800 -t set
    for i in $(seq 10000); do echo $i; pkg=$((RANDOM % 3000000 + 1500)); echo ${pkg}; /root/redis-6.2.9/src/redis-benchmark -h 124.88.25.225 -p 6379 -c 5000 -n 1000000 -d ${pkg} -t set,get --threads 20; done


**[Фактический результат]**, пожалуйста, опишите фактические результаты и влияние
После некоторого времени выполнения команды gazellectl lstack show 1 показывает увеличение счетчика tx_allocmbuf_fail при тестировании команды set, а также снижение RPS до нуля.**[Ожидаемый результат]**, пожалуйста, опишите ожидаемые результаты и влияние.
Непрерывность потока данных и отсутствие роста счетчика tx_allocmbuf_fail.

Комментарий (0)

GitLife Service Account Задача создана
GitLife Service Account добавлено
 
sig/sig-high-perform
label.
Развернуть журнал операций

Вход Перед тем как оставить комментарий

Статус
Ответственный
Контрольная точка
Pull Requests
Связанные запросы на слияние могут быть закрыты после их объединения
Ветки
Дата начала   -   Крайний срок
-
Закрепить/Открепить
Приоритет
Участники(1)
1
https://api.gitlife.ru/oschina-mirror/openeuler-gazelle.git
git@api.gitlife.ru:oschina-mirror/openeuler-gazelle.git
oschina-mirror
openeuler-gazelle
openeuler-gazelle