From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) by dpdk.org (Postfix) with ESMTP id 2E5A62C14 for ; Thu, 14 Apr 2016 19:18:32 +0200 (CEST) Received: by mail-lf0-f67.google.com with SMTP id o124so13188598lfb.2 for ; Thu, 14 Apr 2016 10:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=blJishLKmFt8mKNEXy3hf+7TIcht+wxe+WnQcUEm6gk=; b=bFcyECHfHNKjHJbFJs1z1CA2/O9BDh9aWMVEAlmeZJDh8b0FrpJ62LT0rVyuQzPk36 KuFZRAzhQdaazI4O8yedeGpz7p3k5v5amDFMWZzK3ZHe7s0roVYbpMV4dmsAv+phxlPj peFjQThldgp9/1WOnddYbgMZBrGyY1RNNsRvWkGZWZ49+GP/rJ/aX/ptfenhw6mqqBim 5hokdOdt0o1JGpgim0j792JZS/4siuEMW5VyItOkyr4cZ8/aIJIPaQiTcewA/uE13Iqr SG+UE4QHiwSUa3tSnjxp34BN8jaDGbVZ883vfTKwcBTvYcDaO+CovJn3XBDQDPlg5VVK qMhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=blJishLKmFt8mKNEXy3hf+7TIcht+wxe+WnQcUEm6gk=; b=ckSIaDYX6GKvgNRiU1lFbPMbnaY0aJK3ehhrba7q8bXglxJI7ZkvCk0+P5H62/sNFx jgfrYWhFLDtTFAwmViEN24zPRV4LLDxz64Q1ifhqF9e+GIXLTatM9Ldc7oubSzEzdm3v vwcvs7sqI+oFt4NVVZl3vPZGKvICA9LOiXuwkiad2gLPFBQqKgM8HdY1fDCf6NC8UfIt oHdXdJ4sK5LnbLWBr/I9jDbHpqLuIeMj/Iu9uxLJgIImgg3WJJhRhgpAZsStu0nKJcPj ARRSwVDtH0dPfhXCkQV+QX8ELan55eEyqC5+aXwkpsS0e3MHjuNvzV5FHmdm+lK1hTh3 h23g== X-Gm-Message-State: AOPr4FU7EjTjotJZlIggAiTw0u9VakRgS+SQR0UT6CD51rKSXDrs23df2Tm7+OmXFyf7VA== X-Received: by 10.112.167.37 with SMTP id zl5mr7277603lbb.60.1460654311851; Thu, 14 Apr 2016 10:18:31 -0700 (PDT) Received: from [10.250.153.86] ([31.173.84.82]) by smtp.gmail.com with ESMTPSA id qh4sm6820964lbb.43.2016.04.14.10.18.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 10:18:31 -0700 (PDT) Mime-Version: 1.0 (1.0) From: Alexander Kiselev X-Mailer: iPad Mail (13E233) In-Reply-To: Date: Thu, 14 Apr 2016 20:18:30 +0300 Cc: users@dpdk.org Message-Id: <8CD7A8EE-BCAF-4107-9CEA-8B696B7F4A5C@gmail.com> References: <9485D7B0-E2EA-4D23-BBD9-6D233BDF8E29@gmail.com> <6EBF3C5F-D1A0-4E49-9A16-7FDB2F15E46C@gmail.com> To: Shawn Lewis Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Lcore impact X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 17:18:32 -0000 I've already seen this documen and have used this tricks a lot of times. But= this time I send data locally over localhost. There is even no nics bind to= linux in my machine. Therefore there is no nics interruptions I can pin to c= pu. So what do you propose? > 14 =C1=D0=D2. 2016 =C7., =D7 20:06, Shawn Lewis =CE=C1= =D0=C9=D3=C1=CC(=C1): >=20 > You have to work with IRQBalancer as well >=20 > http://www.intel.com/content/dam/doc/application-note/82575-82576-82598-82= 599-ethernet-controllers-interrupts-appl-note.pdf >=20 > Is just an example document which discuss this (not so much DPDK related).= .. But the OS will attempt to balance the interrupts when you actually want= to remove or pin them down... >=20 >> On Thu, Apr 14, 2016 at 1:02 PM, Alexander Kiselev w= rote: >>=20 >>=20 >>> 14 =C1=D0=D2. 2016 =C7., =D7 19:35, Shawn Lewis =CE=C1= =D0=C9=D3=C1=CC(=C1): >>>=20 >>> Lots of things... >>>=20 >>> One just because you have a process running on an lcore, does not mean t= hats all that runs on it. Unless you have told the kernel at boot to NOT us= e those specific cores, those cores will be used for many things OS related.= >>=20 >> Generally yes, but unless I start sending data to socket there is no pack= et loss. I did about 10 test runs in a raw and everythis was ok. And there i= s no other application running on that test machine that uses cpu cores. >>=20 >> So the question is why this socket operations influence the other lcore? >>=20 >>>=20 >>> IRQBlance >>> System OS operations. >>> Other Applications. >>>=20 >>> So by doing file i/o you are generating interrupts, where those interrup= ts get serviced is up to IRQBalancer. So could be any one of your cores. >>=20 >> That is a good point. I can use cpu affinity feature to bind unterruption= handler to the core not used in my test. But I send data locally over local= host. Is it possible to use cpu affinity in that case? >>=20 >>>=20 >>>=20 >>>=20 >>>> On Thu, Apr 14, 2016 at 12:31 PM, Alexander Kiselev wrote: >>>> Could someone give me any hints about what could cause permormance issu= es in a situation where one lcore doing a lot of linux system calls (read/wr= ite on socket) slow down the other lcore doing packet forwarding? In my test= the forwarding lcore doesn't share any memory structures with the other lco= re that sends test data to socket. Both lcores pins to different processors c= ores. So therotically they shouldn't have any impact on each other but they d= o, once one lcore starts sending data to socket the other lcore starts dropp= ing packets. Why? >>>=20 >=20