From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by dpdk.org (Postfix) with ESMTP id ECB81B3A3 for ; Tue, 26 Aug 2014 18:34:40 +0200 (CEST) Received: by mail-pa0-f44.google.com with SMTP id eu11so23816497pac.31 for ; Tue, 26 Aug 2014 09:38:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=BoM5p+KrUMTXFdyRgc6b/nsFleuPyk0KlgWL1qvRHTI=; b=UiovdtL/MqkwLr4F58DWy459tj+f4d67OAM+9KAwv14NT2/m1ekKZxVEaBkCriEHjp If4GzzBxWhBQBWakZWpKuLLATbUsZVBbGeyZfdEd+gs6NM/SWzUKk+K3OE1lasZ2hjEK YmlHx+qs/ZV+izTAYddxF8WAipFR9TRturjSZPtUASOTSf1N/unAPZAK20gOPFO45Alb eL7Ax6FNe7ID3BrozoMxO7lrvRKDD1vIosyh5daKUcOIVMuOYXsdrEbrsK6ajscSNLJ+ ncnyaMhtig9ku6/bMl537rD4Bq41OSOuLocBSDmdmdAYSY12CZ97EoLwkKTwGf0WuvpG gWnw== X-Gm-Message-State: ALoCoQnkxEGiseV53Zbtg+npZBTa+CE8cz03Gc8aiugqjxbAPh0vKaYozudv9VclwqLXFo09ZYwz X-Received: by 10.70.140.193 with SMTP id ri1mr9020950pdb.18.1409071120743; Tue, 26 Aug 2014 09:38:40 -0700 (PDT) Received: from urahara (static-50-53-65-80.bvtn.or.frontiernet.net. [50.53.65.80]) by mx.google.com with ESMTPSA id pe1sm5451876pdb.85.2014.08.26.09.38.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Aug 2014 09:38:40 -0700 (PDT) Date: Tue, 26 Aug 2014 09:38:37 -0700 From: Stephen Hemminger To: "Michael Marchetti" Message-ID: <20140826093837.4e3d1d4b@urahara> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 26 Aug 2014 16:34:41 -0000 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 there any interest in the community? > > Thanks, > > Mike. Better to implement a NAPI like algorithm that adapts from poll to interrupt.