From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by dpdk.org (Postfix) with ESMTP id BF9E93975 for ; Wed, 27 Aug 2014 06:09:58 +0200 (CEST) Received: by mail-yh0-f54.google.com with SMTP id v1so13080929yhn.27 for ; Tue, 26 Aug 2014 21:14:00 -0700 (PDT) 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:content-type; bh=z8sRaljteypgRN5KKdPXRtRz+lV9YoqYtn6iJeAWQU4=; b=d3u/BwzWVQtq5USXrxaNnUAdAxyxVSAtMJ4Tff1a7pvsdYWzaHrfPxx89PqO2EcoWT ngoiyjy8jSqgtUZm3XBsHKIampoQEOK7VyA+uFbGJmmxNgIUMLMDkPYWh3z0Z5pyyBPh Va9D4M1SPtcnmCtHkQpDghv7eyCHYNQhCK3uacT4nVQYraAXfNt9degiCU09U+VgVRl+ cShfBKVfrbmu/hbIanwGEDVZ7dR0dVTvEuhWMTPDvQhp0+4sw/0+hP+dCrERVL2DL+G2 jjf7KfH2sbsuKlTxUOdF915ChZw+2kGJhiCo9MNUkcdY5lPNTbQG+6wj/Gtz+z4TjpSf 32Jg== X-Gm-Message-State: ALoCoQnOVmb2brTeEOohkSkxNIt7+JIRrAknskV1y6gfBhfpotmGJUI0P7rT6QEx592SBx/S9I4j MIME-Version: 1.0 X-Received: by 10.52.1.39 with SMTP id 7mr3572202vdj.17.1409112840699; Tue, 26 Aug 2014 21:14:00 -0700 (PDT) Received: by 10.220.197.70 with HTTP; Tue, 26 Aug 2014 21:14:00 -0700 (PDT) In-Reply-To: References: <20140826093837.4e3d1d4b@urahara> Date: Tue, 26 Aug 2014 21:14:00 -0700 Message-ID: From: Stephen Hemminger To: "Zhou, Danny" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 04:09:59 -0000 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 there > 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. >