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 8216E45A1E for ; Tue, 24 Sep 2024 18:38:17 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 118484028E; Tue, 24 Sep 2024 18:38:17 +0200 (CEST) Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) by mails.dpdk.org (Postfix) with ESMTP id 5F4E040274 for ; Tue, 24 Sep 2024 18:38:15 +0200 (CEST) Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-6c34c2a7dc7so38461076d6.3 for ; Tue, 24 Sep 2024 09:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1727195895; x=1727800695; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=M4O3n5Oae6IR6S7fgfIe5nTCpHoxXM1zdC5SPPC1ZZ0=; b=yohUWEBnQWGSrf9ICGPdl5FerRw5Bso29qDL0O9IZwqNxU9iayT4OIlQi6sk4EXFuo 3iNwJWdYGPMZu70Xw/v+1rCnNG6d3ghyoOYDCao74qURn2XlLO+Qyfa9ydy/RLV83UzZ N5sRSCSedBtkEdrxonAj5/V+hKb2iMAkmY2y1Xbt5ZwtJ7gPJQLG+mL5BR0FQ+G3PLYv 5K0m/0cyx2oXW9cSnZsDjx0nq72WeOAGGAwTQZ/5rET8ICT6Cf+aq8SAQYtCCZCCLXkg OfWX4/V9xb4ecjY5MXQpRC2IkSa1srQEVGyYMpUESGyiDyHz1srmC0hF7G/sjE7dXDuX 9rXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727195895; x=1727800695; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=M4O3n5Oae6IR6S7fgfIe5nTCpHoxXM1zdC5SPPC1ZZ0=; b=xLOhq9UoPpbq0p3PvTBCW8bIJsOeM0frR9XZfLsWWg581DCJ5GZYbLwDszCqDk70R0 aUMcxJ89LPnEt1SHXUUhDZJ25aOxsTrWJk/hLM+yclMIrQ1jwzqBae8jFnIlt4JCRbyj sf0f51s3qN0PD0gKq716lDcjMXgXLGohFFndMDiHpg2xh50hWZJyOoxojYkK521n5Qje GCjjR1h9UbF2gXKYFEku3SpLlDB56S97dXjdOlT62DbYHSqoisAx4h9CpqXWmPBfFKfr 2OjE1KG7HmaCTFY/MlRCbn8clg9MRExESUK+Ixt8xNeEsYKekwrIlpOmxrCrqIKzLfxc iLCg== X-Forwarded-Encrypted: i=1; AJvYcCWlkM/q0hW+xItTmzZhqIR+qLs1OC12R85iHrKrpevnVzkrJiZ5z6uoeq/Y/2+plHs3fsMKWg==@dpdk.org X-Gm-Message-State: AOJu0Yy2CgLVfgyP47xPmTrpnehjOuiUKqrbaZN+E5sAB+GMoa+bEvg5 DjPTsC6w5wgqXk/fJUwZL1XrQByzhWlCSeir4D9DqBWIXcmahSG9UxyskVaTk1M= X-Google-Smtp-Source: AGHT+IFtXQBVoJKNUSjews5b+W/f2m26KmjH7qOcEDkuuSqsMzPDidi0LrXZPD/T71f+KqaFgN80KQ== X-Received: by 2002:a05:6214:4993:b0:6c5:c16e:22cf with SMTP id 6a1803df08f44-6c7bc6148demr244775726d6.10.1727195894697; Tue, 24 Sep 2024 09:38:14 -0700 (PDT) Received: from fedora ([173.242.185.50]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6cb0f4ebacdsm7997016d6.73.2024.09.24.09.38.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Sep 2024 09:38:14 -0700 (PDT) Date: Tue, 24 Sep 2024 09:38:13 -0700 From: Stephen Hemminger To: amit sehas Cc: Nishant Verma , "users@dpdk.org" Subject: Re: core performance Message-ID: <20240924093813.29a01783@fedora> In-Reply-To: <2042269904.11975457.1727188849962@mail.yahoo.com> References: <1987164393.11670398.1727125003663.ref@mail.yahoo.com> <1987164393.11670398.1727125003663@mail.yahoo.com> <1299564509.11731667.1727133474900@mail.yahoo.com> <2025533199.11789856.1727143607670@mail.yahoo.com> <2042269904.11975457.1727188849962@mail.yahoo.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Tue, 24 Sep 2024 14:40:49 +0000 (UTC) amit sehas wrote: > Thanks for your response, and thanks for your input on the set_priority,= =C2=A0 >=20 > The best guess we have at this point is that this is not a dpdk performan= ce issue. This is an issue with some threads running into more context swit= ches than the others and hence not getting the same slice of the CPU. We ar= e certain that this is not a dpdk performance issue, the code > is uniformly slow in one thread versus the other and the threads are doin= g a very large amount of work including accessing databases. The threads in= question are not really doing packet processing as much as other work. >=20 > So this is certainly not a dpdk performance issue. This is an issue of ke= rnel threads not being scheduled properly or in the worse case the cores ru= nning on different frequency (which is quite unlikely no the AWS Xeons we a= re running this on). >=20 > If you are asking for the dpdk config files to check for dpdk related per= formance issue then we are quite certain the issue is not with dpdk perform= ance ... > On Mon, Sep 23, 2024 at 10:06=E2=80=AFPM amit sehas wro= te: > > Thanks for your response, i am not sure i understand your question ... = we have our product that utilizes dpdk ... the commands are just our server= commands and parameters ... and the lscpu is the hyperthreaded 8 thread Xe= on instance in AWS ... The rules of getting performance in DPDK: - use DPDK threads (pinned) for datapath - use isolated CPU's for those DPDK threads - do not do any system calls - avoid floating point You can use tracing tools like strace or BPF to see what the thread is doin= g.