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.
Thanks, Rashmin 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 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 <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 > 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. >
