From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 5BBDC5942 for ; Wed, 27 Aug 2014 07:45:19 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 26 Aug 2014 22:49:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,408,1406617200"; d="scan'208";a="593835826" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga002.jf.intel.com with ESMTP; 26 Aug 2014 22:49:14 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 26 Aug 2014 22:48:39 -0700 Received: from fmsmsx105.amr.corp.intel.com ([169.254.5.78]) by FMSMSX110.amr.corp.intel.com ([169.254.14.56]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 22:48:38 -0700 From: "Patel, Rashmin N" To: Stephen Hemminger Thread-Topic: [dpdk-dev] overcommitting CPUs Thread-Index: Ac/BSK4Ie9dEDL+WSrSuFei6WRfr+QAPi2CAAAC4VAAAF5DiAP//pRid Date: Wed, 27 Aug 2014 05:48:38 +0000 Message-ID: References: <20140826093837.4e3d1d4b@urahara> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] overcommitting CPUs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 05:45:19 -0000 You're right and I've felt the same harder part of determinism with other h= ypervisors' soft switch solutions as well. I think it's worth thinking abou= t. Thanks, Rashmin On Aug 26, 2014 9:15 PM, Stephen Hemminger wro= te: The way to handle switch between out of poll mode is to use IRQ coalescing parameters. You want to hold off IRQ until there are a couple packets or a short delay. Going out of poll mode is harder to determine. On Tue, Aug 26, 2014 at 9:59 AM, Zhou, Danny wrote: > > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > > Sent: Wednesday, August 27, 2014 12:39 AM > > To: Michael Marchetti > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] overcommitting CPUs > > > > On Tue, 26 Aug 2014 16:27:14 +0000 > > "Michael Marchetti" wrote: > > > > > Hi, has there been any consideration to introduce a non-spinning > network driver (interrupt based), for the purpose of overcommitting > > CPUs in a virtualized environment? This would obviously have reduced > high-end performance but would allow for increased guest > > density (sharing of physical CPUs) on a host. > > > > > > I am interested in adding support for this kind of operation, is ther= e > any interest in the community? > > > > > > Thanks, > > > > > > Mike. > > > > Better to implement a NAPI like algorithm that adapts from poll to > interrupt. > > Agreed, but DPDK is currently pure poll-mode based, so unlike the NAPI' > simple algorithm, the new heuristic algorithm should not switch from > poll-mode to interrupt-mode immediately once there is no packet in the > recent poll. Otherwise, mode switching will be too frequent which brings > serious negative performance impact to DPDK. >