[dpdk-dev] overcommitting CPUs
Patel, Rashmin N
rashmin.n.patel at intel.com
Wed Aug 27 07:48:38 CEST 2014
You're right and I've felt the same harder part of determinism with other hypervisors' soft switch solutions as well. I think it's worth thinking about.
On Aug 26, 2014 9:15 PM, Stephen Hemminger <stephen at networkplumber.org> wrote:
The way to handle switch between out of poll mode is to use IRQ coalescing
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 <danny.zhou at intel.com> wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> > Sent: Wednesday, August 27, 2014 12:39 AM
> > To: Michael Marchetti
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] overcommitting CPUs
> > On Tue, 26 Aug 2014 16:27:14 +0000
> > "Michael Marchetti" <mmarchetti at sandvine.com> 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
> 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.
More information about the dev