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 03B2C457E4; Fri, 16 Aug 2024 14:11:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8D4294025D; Fri, 16 Aug 2024 14:11:50 +0200 (CEST) Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) by mails.dpdk.org (Postfix) with ESMTP id AE4CD400EF for ; Fri, 16 Aug 2024 14:11:48 +0200 (CEST) Received: by mail-oi1-f172.google.com with SMTP id 5614622812f47-3db18102406so1061144b6e.1 for ; Fri, 16 Aug 2024 05:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723810308; x=1724415108; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=b/R7b7ffoCc0lZofVJoDU8m9oO/nJaP+2s+PJRORdoA=; b=fI7NAUKpC75nG0yrhf3HPLhWDqb3ztiPXSlf/y7mCkc3L4TGAPIiyGRgJHMgOvcdLW T04dmcU2LfQS+JPTojD+1NrOcSLvgnXpdQC0X7hSdPNq7dqE2M48dQvtkozysd5GtuZc OkrBLe9lIFZXw4I3y/mComStoJnogyjLnsygI8HOOLCetEDhxJd1+e34CBon+p1BJ7TO KQDHXYMWFO96TBad14FAghVdaf+5eW0wZi2BP5m9EIXjpYHLWTsuwAJJLBezIMq+8Fun 21u6TxvYHBisBTsm+sRNQDSHItlc9UeW9k0XQd/o2HbMxaiLrGmB4t9rL98htgJGa8Z6 p2Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723810308; x=1724415108; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=b/R7b7ffoCc0lZofVJoDU8m9oO/nJaP+2s+PJRORdoA=; b=hQN+2UHLmt8rXBXP1yJkQJNvUHDZcJpVVtgwkPfHXSVAV73v3iF7sbqiIlKPAaXvN+ vj72JjHjaWFI5TyvTwxk4izO/+BOZOfyBbGzCJlKQgXiBFJWxNFbMvOoHovAQMAu3vDA 4UxKhTIloU1uHhoZXnK74UdblCKpSeu6GkT4YOAPsn5muym+9s6cz6dSJPdEvc/ZPUn8 /XM/qb3i0LlO8GwvgwoIObpxD0RiezzOhCViQS13KaLLZRMAc1vFAOHdDbeKARHqBJdw A+3XUEy0lqGxpJebIWVCaLvxglb9LEWb93x8jxi88sRRXBGKEhWgMh0PErpIT8sQsyu/ 8/FA== X-Gm-Message-State: AOJu0Yx2XxJMYZwV6bi+qxdXKoUHzusa7t8X8Ec5pSoRNhI15vn0q4t/ BBKjiVe7GfyiOfw8tEh6fSY3yLPKM18frLU25tnKcaEB42YGQpc/49zSTEDBMKIwHJF/mdpg4Gl uvpZU1hSNZguDQirMZzV/yal1dkw= X-Google-Smtp-Source: AGHT+IEJ1B4P0M1whwAKBpPSmSqkQKWYC13eVeohHMcVRUJJ5VufBG4SyrwxzCYPADxs/EKECJ88hXUEGJ+wRs/Hvcc= X-Received: by 2002:a05:6808:3099:b0:3d9:2920:bc2f with SMTP id 5614622812f47-3dd3acae303mr2818485b6e.10.1723810307712; Fri, 16 Aug 2024 05:11:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jerin Jacob Date: Fri, 16 Aug 2024 17:41:21 +0530 Message-ID: Subject: Re: Ethdev tracepoints optimization To: Adel Belkhiri Cc: dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Fri, Aug 16, 2024 at 4:43=E2=80=AFAM Adel Belkhiri wrote: > > Hi DPDK Community, > > I am currently working on developing performance analyses for application= s using the ethdev library. These analyses are being implemented in Trace C= ompass, an open-source performance analyzer. One of the views I=E2=80=99ve = implemented shows the rate of traffic received or sent by an ethernet port,= measured in packets per second. However, I've encountered an issue with th= e lib.ethdev.rx.burst event, which triggers even when no packets are polled= , leading to a significant number of irrelevant events in the trace. This b= ecomes problematic as these "empty" events can overwhelm the tracer buffer,= potentially causing the loss of more critical events due to their high fre= quency. > > To address this, I've modified the DPDK code in lib/ethdev/rte_ethdev.h t= o add a conditional statement that only triggers the event when nb_rx > 0. = My question to the community is whether there are use cases where an "empty= " lib.ethdev.rx.burst event could be useful. If not, would there be interes= t in submitting a patch with this modification? > > Moreover, I am looking to develop an analysis that calculates the through= put (in kb/s, mb/s, etc.) per NIC, utilizing the same events (i.e., lib.eth= dev.rx.burst and lib.ethdev.tx.burst). These tracepoints do not provide pac= ket size directly, only a pointer to the packet array. My attempt to use an= eBPF program to iterate through that array to access the packet sizes was = unsuccessful, as I found no method to export the computed data (e.g., via a= custom tracepoint). Does anyone have suggestions or alternative approaches= for achieving a throughput measurement? Call rte_eth_stats_get() in N second interval and find throughput in slow p= ath. > I would be grateful for any insights or suggestions you might have. > > Thank you! > Adel