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 D098343D99; Mon, 6 May 2024 20:04:18 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5C90540E54; Mon, 6 May 2024 20:00:04 +0200 (CEST) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by mails.dpdk.org (Postfix) with ESMTP id 600834067D for ; Mon, 6 May 2024 20:00:03 +0200 (CEST) Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1e651a9f3ffso9602645ad.1 for ; Mon, 06 May 2024 11:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1715018402; x=1715623202; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=QTnwNDRJt5w2X+ucof2W9pkV6sDyLLDLoqpjSpbLs9o=; b=bXIvG7xuf3H40y7+YTQtk/znGPbxElIQ7emIOR8mGxdDo2MZaUmn8XMvdjwyDEDO98 jIn2wKogK8sXcH96DhuOURmIs2VR7zM33mFw94vSv0t8XL2tk2N8TLFgD9RfJvyCdJgS xcbFw5hBhncA9M6dpLtwhHLjLkAjhzVn481k/z6Zh8n5dvGmP+OdmkeuKWA/K+lJGFka 2n6TQsyme/fFjArjyMyK7Lnbi6xw7nsDuwwUVhUX7lJOvD4MWA+ClPV7MNuDRf9OvEZq VIuLi9YWB7BGGiHws+utf7zqa7smv8gQKOUIGmledLC+VtJHwHHoVoDx19IGITC7ghEc Tv1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715018402; x=1715623202; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QTnwNDRJt5w2X+ucof2W9pkV6sDyLLDLoqpjSpbLs9o=; b=LuqJmtqpBQCVPzsS11He5RYhZUPmYBoWVQWShm7TT+OiT9ht4AqF9NuMUmd1gTdrFr diIfQy3PNiYNd8W3tBDa1djUMVxTYSB9ndJRj0TQwCgdssCKOb+1KGWQ/AjCG3jtC573 XlBSvGh3uhMuOrBl1k2/Ccym5Poaga5zOH+rTliKICCKVbFmGLhD5wxnsqP8HHaWeEI/ qIcK4UNFdq4eOCE35UCcXO1lFIQ0PiLcxigHq75LQBcHEriTGJqaGQpVEhvmYvEHITyq foA0zLk110zSHLJ09VNVmdd/f/4p0oGGsnAiFTgT13qjNQZdprooD8K72T29tZVIf/Rj DESQ== X-Forwarded-Encrypted: i=1; AJvYcCVcJGK1gaQ4EO27rtA2HP60n1orM+uIu/8u3efLiWq9GAU0+41FT3SxDEKBo/0F877nLqLqDkBi40EDv0Q= X-Gm-Message-State: AOJu0YxrykIrqJdQ8vdTsqX2C8KGam8/P+m8uM8EwSxNXIICyYSkUkzv ROplTG/litwi/ImI72uDhZZyVmiIf0ReCXbV3U93+tALjWe7TOH0swPcQJRWeac= X-Google-Smtp-Source: AGHT+IFYzawxjSfcGe1XjksbYwNUW9jQpQdUsVcShMvAjotRhdrBm5mJi7UMwmH2HQCsL5mrmMuPiQ== X-Received: by 2002:a17:902:d355:b0:1eb:3e13:ca0b with SMTP id l21-20020a170902d35500b001eb3e13ca0bmr9421728plk.37.1715018402377; Mon, 06 May 2024 11:00:02 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d12-20020a170903230c00b001ee63a7c85dsm130684plh.287.2024.05.06.11.00.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 May 2024 11:00:02 -0700 (PDT) Date: Mon, 6 May 2024 10:59:59 -0700 From: Stephen Hemminger To: Fuji Nafiul , dev@dpdk.org Subject: Re: High packet capturing rate in DPDK enabled port Message-ID: <20240506105959.4bce7265@hermes.local> In-Reply-To: References: <20240505090256.5e2d916f@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, 6 May 2024 02:15:10 +0600 Fuji Nafiul wrote: > I understand that I will need more cores and SSD, which I have. The thing > is is there any current project available that exposes params to dump the > highest possible rate with available resources? or I have to use the pdump > framework and implement it myself. I previously wrote dumping code > integrated with my dpdk media which was able to dump around 0.5 Gbits/s (1 > big rte ring and 2 cores, not much optimized) then found out that pdump > framework does a similar kind of thing but just with a secondary process > with interception in rx/tx. But I need to modify to scale it, That is why I > was wondering whether there is already a project that aims to dump the > highest rate possible in dpdk port, otherwise, I will start modifying it. I > haven't looked into "dpdkcap" code but it says that it aims to dump around > 10Gbit/s if resources are available. Has anyone used or tested this project > or tried to modify pdump code to scale? The things that could speed up dpdk-dumpcap are: 1. Use Linux async io via ioring. But creates work around supporting older distros. I would not make it an option, if ioring works it should be used. Might be easier not that RHEL/CentOS 7 is end of life and does not need to be supported. 2. Get rid of copy in pdump side by using ref counts. But this exposes potential issues with drivers and applications that don't handle mbufs with refcount > 1. It means if refcount > 1 then the application can not overwrite the buffer. On Tx side, that means handling vlan gets more complicated. On Rx side, it needs to be an option; and most applications (especially 3rd party) can't handle refcounts. 3. Get rid of callback and just put mbuf into ring directly. Indirect calls slow things down and introduces bugs when secondary is doing rx/tx. 4. Have dumpcap use multithreads (one per queue) when doing ring -> write. These are in order of complexity/performance gain. I haven't done them because don't work full time on this. And it would require lots of testing effort as wel.