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:de
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 +
>> >
> -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 1
ailto:dev-bounces at dpdk.org] On Behalf Of Michael Marchetti
> Sent: Wednesday, August 27, 2014 12:27 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] overcommitting CPUs
>
> Hi, has there been any consideration to introduce a non-spinning network
> driver (interr
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 Tue, 26 Aug 2014 16:27:14 +
"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
>
6 matches
Mail list logo
