From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f66.google.com (mail-lf0-f66.google.com [209.85.215.66]) by dpdk.org (Postfix) with ESMTP id 614DE298F for ; Thu, 14 Apr 2016 19:02:15 +0200 (CEST) Received: by mail-lf0-f66.google.com with SMTP id o124so13126832lfb.2 for ; Thu, 14 Apr 2016 10:02:15 -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=S31UDbSoqwoTQ/EZXkC9blHel+vsM3P7wy33hb+WlRc=; b=RA1xGUbHQlab+gBd5Vbsfo8HgdQ0EB41XSMwCC+NPt//fJeK6ulauD4/P7w+8jNbpZ gOZtibaJx2U9Qvq7sjImpUZRG8YojdbPBjk3pWHfmP8h5rL7KWa6iNqiz2VZOiCXPOWl ohhWspwGexJQ3ZYUURmLXnqs00NvHnB846VJnnUWvs9kMJmV3pBAenJrCN77NoT4zVHE RPQAHZbLd716ulweH0tXtuVHi0QLvwCKTPiNLbUOCrbgfkdV9LpT/mIE8KpahTF0tALE ysnCtOuM0BVro2Xok7N0zDFcJNL6kUNb4QmQ5xkpt4Xex3/zcxA4HwuggG0RIaWhgCSi slWA== 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=S31UDbSoqwoTQ/EZXkC9blHel+vsM3P7wy33hb+WlRc=; b=B83xNn1sgJMRUeI/TkQl37gWHbfKxcfs7Kb89OXsUoQKnDYSfqeg10qKrlB6yx94FA vpvOhF9Vtz/HmXaBAdPhKEK46YxpW8anKH3wWkANdYfs/H+f+H4hED75cUJJzvvVkelP cuE3Ap43D2L13RQ6RTY7jT1FNpTVazfRYbU8FAyjL5V4rASySIZIkTrC+eD2GsqlblDF HxX64kVNONQcWtLA/eCViv5ESIBBfL0TEh0MWUfxF7VRdMp5BDlLC3rppRybmiy5MO4e 8nwxehqC+UBZ4m+/zPRJcEDo56aXK+pPk0xAQ6QnZn+RA5wQQIEywicdjg5GOUBfvJ/B QE8A== X-Gm-Message-State: AOPr4FUIP13fKNCxctrrm4EHSjKMPweklUFS3yaIqAwjnnGCUmFF7XpdfD6d3ShH2fmY8Q== X-Received: by 10.25.88.133 with SMTP id m127mr5773381lfb.156.1460653335004; Thu, 14 Apr 2016 10:02:15 -0700 (PDT) Received: from [10.250.153.86] ([31.173.84.82]) by smtp.gmail.com with ESMTPSA id 102sm6998923lfy.41.2016.04.14.10.02.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 10:02:14 -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:02:13 +0300 Cc: users@dpdk.org Message-Id: <6EBF3C5F-D1A0-4E49-9A16-7FDB2F15E46C@gmail.com> References: <9485D7B0-E2EA-4D23-BBD9-6D233BDF8E29@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:02:15 -0000 > 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 tha= ts all that runs on it. Unless you have told the kernel at boot to NOT use t= hose specific cores, those cores will be used for many things OS related. Generally yes, but unless I start sending data to socket there is no packet l= oss. I did about 10 test runs in a raw and everythis was ok. And there is n= o other application running on that test machine that uses cpu cores. So the question is why this socket operations influence the other lcore? >=20 > IRQBlance > System OS operations. > Other Applications. >=20 > So by doing file i/o you are generating interrupts, where those interrupts= get serviced is up to IRQBalancer. So could be any one of your cores. That is a good point. I can use cpu affinity feature to bind unterruption ha= ndler to the core not used in my test. But I send data locally over localhos= t. Is it possible to use cpu affinity in that case? >=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 issues= in a situation where one lcore doing a lot of linux system calls (read/writ= e on socket) slow down the other lcore doing packet forwarding? In my test t= he forwarding lcore doesn't share any memory structures with the other lcore= that sends test data to socket. Both lcores pins to different processors co= res. 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