From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com [209.85.161.180]) by dpdk.org (Postfix) with ESMTP id 4E0E6298F for ; Thu, 14 Apr 2016 19:06:13 +0200 (CEST) Received: by mail-yw0-f180.google.com with SMTP id d68so110436680ywe.1 for ; Thu, 14 Apr 2016 10:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tencara-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=MUeOOKKsXERpeVwSXrNagGvjeeVX1eW+cIB9ywd/pzo=; b=pguqmmlLD6VRLI7t3k5WyImVPSokAsO+Kw+604NUtBTd6c/98U0rHl7qtlXtNOs6ed GnZTOZ/UPojzMzT7UpHSazgMGFL+RMvwXM3BC+iO5Ir/og8ukfNhvraJXS1Em7sl3/0p eba1XmCeEzbI13aanJdsJoOZqZVVZl9UnDHfPIejmka3+QshN7g5VdLL9lsjAYITdcWQ +fRPJ38ZRTgVesNcrle8ZAQ/clH1vfUu4Cp056mVx+LFnBtrIw9Rc6gomzs/iiL4tAKw mX2eKcGuhYjh3sfhrq6wKl6J7L5AYa14gw644MEvQX36+YTcwxIISDyTqI/IpnCCC54g ODhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MUeOOKKsXERpeVwSXrNagGvjeeVX1eW+cIB9ywd/pzo=; b=mpBSRTcFEE/JwOdH5my0mlVVzJg/YvZf5y97Rh0+HV1lA1PQgZYMAX2m0XM3O76LsA i8GjTxSY512/+tauzavu/rpWhQFJUd6GRWti1O4ZHpv2sabFmsDxachoAdKf1J1bDN/e DOSlILTq6HvNmebN5wkzfMTYYFk0mqraQAfUzOW0j8mNWoZqMV1tu0o+yMjh5SuaRDWf ukVjiZBFZ+Nd5CYghG09spwxqaQ/tB8puzxLZcMNzZLbQMXM0RmYAjARWKwNp5RAE+yb HrerWEA3fM0U62GCVWLHjjIB+X5aW45H4pGo7O9RH6bQ6m/GQihfCwo0Tj25DODEpIVD C8pw== X-Gm-Message-State: AOPr4FVlJvvmJv7Jkk359h+Ho8jJIhWE60hnmAVizKmOfBDH76wMT3Yhb/Z6XGxj009cA6NP4TmJg1JeMaRElQ== MIME-Version: 1.0 X-Received: by 10.37.0.66 with SMTP id 63mr8401513yba.134.1460653572766; Thu, 14 Apr 2016 10:06:12 -0700 (PDT) Received: by 10.37.198.70 with HTTP; Thu, 14 Apr 2016 10:06:11 -0700 (PDT) In-Reply-To: <6EBF3C5F-D1A0-4E49-9A16-7FDB2F15E46C@gmail.com> References: <9485D7B0-E2EA-4D23-BBD9-6D233BDF8E29@gmail.com> <6EBF3C5F-D1A0-4E49-9A16-7FDB2F15E46C@gmail.com> Date: Thu, 14 Apr 2016 13:06:11 -0400 Message-ID: From: Shawn Lewis To: Alexander Kiselev Cc: users@dpdk.org Content-Type: text/plain; charset=UTF-8 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:06:13 -0000 You have to work with IRQBalancer as well http://www.intel.com/content/dam/doc/application-note/82575-82576-82598-825= 99-ethernet-controllers-interrupts-appl-note.pdf 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... On Thu, Apr 14, 2016 at 1:02 PM, Alexander Kiselev wrote: > > > 14 =D0=B0=D0=BF=D1=80. 2016 =D0=B3., =D0=B2 19:35, Shawn Lewis =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): > > Lots of things... > > One just because you have a process running on an lcore, does not mean > thats all that runs on it. Unless you have told the kernel at boot to NO= T > use those 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 loss. I did about 10 test runs in a raw and everythis was ok. And > there is no other application running on that test machine that uses cpu > cores. > > So the question is why this socket operations influence the other lcore? > > > IRQBlance > System OS operations. > Other Applications. > > So by doing file i/o you are generating interrupts, where those interrupt= s > 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 > handler to the core not used in my test. But I send data locally over > localhost. Is it possible to use cpu affinity in that case? > > > > > On Thu, Apr 14, 2016 at 12:31 PM, Alexander Kiselev > wrote: > >> Could someone give me any hints about what could cause permormance issue= s >> in a situation where one lcore doing a lot of linux system calls >> (read/write 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 lcore that sends test data to socket. Both lcores pins to >> different processors cores. So therotically they shouldn't have any impa= ct >> on each other but they do, once one lcore starts sending data to socket = the >> other lcore starts dropping packets. Why? >> > >