From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2C821458FA for ; Wed, 4 Sep 2024 04:58:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9EFA040299; Wed, 4 Sep 2024 04:58:20 +0200 (CEST) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by mails.dpdk.org (Postfix) with ESMTP id 765064028A for ; Wed, 4 Sep 2024 04:58:16 +0200 (CEST) Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-5c275491c61so1213036a12.0 for ; Tue, 03 Sep 2024 19:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khomp.com; s=google; t=1725418696; x=1726023496; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=CLxUBQM0Ns06xzpRq+shUihH+4+FgEWICsxMttVqg9o=; b=kwba3b2zsPdsRAtJwiBc5DmRlbXWoog0aNCsGJj8ODDa6bPsFKojXhQwBMaHPj0Q9j hLpENQAY2TeY08l1Chw5kD4ClajKU3q7X5T9lUdfs2yu6T19sWKLZlGPivT/BUJXBP6U hl3yXT0VoHY83EYBpuNq9kipFrtdVwJbC5kmM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725418696; x=1726023496; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=CLxUBQM0Ns06xzpRq+shUihH+4+FgEWICsxMttVqg9o=; b=cwCXUTem1kDFctT2w/YQ6aDC2ZgeoZ6UDH7tYqpZcJ721LlJljBALfL0+aI52hVauZ 6eWSAKip9CHzoUT6Gs0pEeYq+EAUt2SdiTilIFOAeEkZVhyoltoBVvnYVkgHY/wacj6o juo8YlHiEbLjtiOXarfFsp4RwU5MdNwLk8oG2Y9dSH+YdzmIp5LOJVzLAACzaIC8ngYO 27CmFiMsVDq/Kq+uFKVS5ZHwjw4zulV3gcY4R2By+kejTiPa8GO4kpZbzWpCb41U976t C+ZU2dH98/qyZdmpGmdDHjIMvvP4x5GzwNvkvyBHlplrrTR19oIilVd/2vae71+4Pwtk QRqg== X-Gm-Message-State: AOJu0YxRWJxcbCt4844yt/yuoDTBbUNdQXhS4fEslirAOrqNCvEGxqVI oQkgvOXYqyzvdII9WX/rC7J4zeH9RfLo0/o8zBOJK1iBQ+0ylPRRg5kh5LTyWz76PMR3yafajCt vjhX1cBcfbzDVRxLQQoyDi+jR3t4/bChBVh0uyUCLYSVfQkHKXCE= X-Google-Smtp-Source: AGHT+IEWvGa+rUt3XW2P1u6qy/P0qWr9MuSqN9r4I7zcBp6hUkU9HaEl7mWAmBz1xpAGfNyuTMUwVpHvTaAFwu2UuGg= X-Received: by 2002:a05:6402:518e:b0:5be:fc44:d159 with SMTP id 4fb4d7f45d1cf-5c21ed52ba1mr15005721a12.22.1725418695925; Tue, 03 Sep 2024 19:58:15 -0700 (PDT) MIME-Version: 1.0 From: Rafael Vargas Date: Tue, 3 Sep 2024 16:58:04 -1000 Message-ID: Subject: Interface stop receiving packets To: users@dpdk.org Content-Type: multipart/alternative; boundary="00000000000075bb45062142588a" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --00000000000075bb45062142588a Content-Type: text/plain; charset="UTF-8" Hi, I have an application using DPDK and it mostly works (my main goal is to accelerate UDP packet forwarding using a set of rules). I currently have two problems: 1 - rte_eth_rx_burst eventually starts returning always 0, and the stats.imissed counter starts to count up. The application is working normally, receiving packets, applying the rules and adding them to the correct tx queue and it just stops receiving packets. The loop keeps calling rte_eth_rx_burst bit the return value is always zero and all the packets sent to the interface are lost. 2 - the rx rings of the vlinks seem to take much longer to be consumed by the OS stack than it would be if the OS were controlling the interface. The vlink is created with rte_eal_hotplug_add( "vdev", "virtio_user0", "path=/dev/vhost-net,queues=1,queue_size=4096,iface=ens224,mac=XX:XX:XX:XX:XX:XX" ) When using the same scenario without the DPDK layer (directly using the OS network stack features for the interface) I can handle more traffic. When enabling the DPDK layer, the rings are constantly full and several packets get lost. Sometimes even with low traffic the the rings don't reach full capacity but take a long time to be emptied by the OS. Most of my tests are using the vmxnet3 adapter, but I have similar results with i40e. Also the results are the same with DPDK 22.11.1 and 23.11.1, All tests using Debian 11. Has anyone seen behaviors like this? And how would I approach solving them? Thanks in advance! -- Rafael Vargas --00000000000075bb45062142588a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have an application us= ing DPDK and it mostly works (my main goal is to accelerate UDP packet forw= arding using a set of rules).

I currently have two= problems:
1 - rte_eth_rx_burst eventually starts returning alway= s 0, and the stats.imissed counter starts to count up.
=C2=A0=C2= =A0=C2=A0=C2=A0 The application is working normally, receiving packets, app= lying the rules and adding them to the correct tx queue and it just stops r= eceiving packets. The loop keeps calling rte_eth_rx_burst bit the return va= lue is always zero and all the packets sent to the interface are lost.
<= /div>

2 - the rx rings of the vlinks seem to take much l= onger to be consumed by the OS stack than it would be if the OS were contro= lling the interface. The vlink is created with

rte_eal_hotplug_add( "vdev", "virtio_user0", "pa= th=3D/dev/vhost-net,queues=3D1,queue_size=3D4096,iface=3Dens224,mac=3DXX:XX= :XX:XX:XX:XX" )

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 When using the same scenario without the DPDK layer (directly using the= OS network stack features for the interface) I can handle more traffic. Wh= en enabling the DPDK layer, the rings are constantly full and several packe= ts get lost. Sometimes even with low traffic the the rings don't reach = full capacity but take a long time to be emptied by the OS.

<= /div>
Most of my tests are using the vmxnet3 adapter, but I have simila= r results with i40e. Also the results are the same with DPDK 22.11.1 and 23= .11.1, All tests using Debian 11.

Has anyone = seen behaviors like this? And how would I approach solving them?
<= div>
Thanks in advance!
--
Rafael Var= gas

--00000000000075bb45062142588a--