Dear Manager
Have a nice day
This is Jerry from Shenzhen of China, writing to you to enter into business
relationship with you. We are the professional manufacturer
with nearly 6 years of experience oversea business in supplying USB Flash
Drives, Tablet PC, Keyboard, Mouse, MP3, Digital Photo
Karim,
On Mon, Nov 19, 2012 at 02:57:24PM -0500, Karim Fodil-Lemelin wrote:
K> While testing the latest igb driver in CURRENT I came across an issue
K> with igb_mq_start(). More specifically this code:
K>
K> ...
K>
K> struct mbuf *pm = NULL;
K> /*
K> ** Try to queue
Gleb,
On 20/11/2012 6:18 AM, Gleb Smirnoff wrote:
Karim,
On Mon, Nov 19, 2012 at 02:57:24PM -0500, Karim Fodil-Lemelin wrote:
K> While testing the latest igb driver in CURRENT I came across an issue
K> with igb_mq_start(). More specifically this code:
K>
K> ...
K>
K> struct mbuf *pm
On Tue, Nov 20, 2012 at 3:18 AM, Gleb Smirnoff wrote:
> Karim,
>
> On Mon, Nov 19, 2012 at 02:57:24PM -0500, Karim Fodil-Lemelin wrote:
> K> While testing the latest igb driver in CURRENT I came across an issue
> K> with igb_mq_start(). More specifically this code:
> K>
> K> ...
> K>
> K>
Anyone who even mentions polling should be discounted altogether. Polling
had value when you couldn't control the interrupt delays; but interrupt
moderation allows you to pace the interrupts any way you like without
the inefficiencies of polling.
The idea that polling uses less CPU is complete bal
On Nov 20, 2012, at 3:52 PM, Barney Cordoba wrote:
> Anyone who even mentions polling should be discounted altogether. Polling
> had value when you couldn't control the interrupt delays; but interrupt
> moderation allows you to pace the interrupts any way you like without
> the inefficiencies of
On 11/20/12 2:42 PM, Jim Thompson wrote:
On Nov 20, 2012, at 3:52 PM, Barney Cordoba wrote:
Anyone who even mentions polling should be discounted altogether. Polling
had value when you couldn't control the interrupt delays; but interrupt
moderation allows you to pace the interrupts any way you
It's not an "opinion"; it obvious to anyone who had a mild understand of what
pollingis. You've never compared it to moderation, which is what you should be
using, becauseyou don't understand what you're doing.
If you set interrupt moderation to 2000 ints/sec, you're doing exactly the same
thing
Am 20.11.2012 23:49, schrieb Alfred Perlstein:
On 11/20/12 2:42 PM, Jim Thompson wrote:
On Nov 20, 2012, at 3:52 PM, Barney Cordoba
wrote:
You're entitled to your opinion, but experimental results have tended
to show yours incorrect.
Jim
Agree with Jim. If you want pure packet performance
--- On Tue, 11/20/12, Ingo Flaschberger wrote:
> From: Ingo Flaschberger
> Subject: Re: FreeBSD boxes as a 'router'...
> To: freebsd-net@freebsd.org
> Date: Tuesday, November 20, 2012, 6:04 PM
> Am 20.11.2012 23:49, schrieb Alfred
> Perlstein:
> > On 11/20/12 2:42 PM, Jim Thompson wrote:
> >>
Barney - I would certainly love to see some real evidence to backup such a
ridiculous claim.
I agree here as well with Jim. I have a ton of experience with and without. I
haven't done enough testing with FreeBSD 9 to state 100% but I can state that
extensive testing and filtering traffic (speci
I got side tracked and missed the new system question.
In a newer system with an Intel em card then you likely won't need it. However
don't play with the HZ settings. If you still see the delays recompile with
polling on default.
Verify on the NIC as well such as ifconfig em0
If it isn't on yo
Ok, so since people are talking about it, and i've been knee deep in
at least the older intel gige interrupt moderation - at maximum pps,
how exactly is the interrupt moderation giving you a livelock
scenario?
The biggest benefit I found when doing some forwarding work a few
years ago was to write
I may be misstating.
Specifically under high burst floods either routed or being dropped by pf we
would see the system go unresponsive to user-level applications / SSH for
example.
The system would still function but it was inaccessible. To clarify as well
this was any number of floods or atta
The next time you have a chance to do high PPS tests, please compile
in KTR and take a schedgraph trace or two.
Read the schedgraph.py source in /usr/src/tools/ for a quick overview.
It'd be nice to have a public record somewhere of this issue
diagnosed. It may have just been some of the really o
Thank you,
I certainly will.
On Nov 20, 2012, at 8:23 PM, "Adrian Chadd" wrote:
> The next time you have a chance to do high PPS tests, please compile
> in KTR and take a schedgraph trace or two.
>
> Read the schedgraph.py source in /usr/src/tools/ for a quick overview.
>
> It'd be nice to h
Am 21.11.2012 00:30, schrieb Barney Cordoba:
--- On Tue, 11/20/12, Ingo Flaschberger wrote:
stems (Intel 82541GI) polling prevent live-locks.
Best test:
Loop a GigE Switch, inject a Packet and plug it into the
test-box.
Yeah, thats a good real-world test.
To me "performance" is not "burnin
On 11/20/12 3:30 PM, Barney Cordoba wrote:
--- On Tue, 11/20/12, Ingo Flaschberger wrote:
From: Ingo Flaschberger
Subject: Re: FreeBSD boxes as a 'router'...
To: freebsd-net@freebsd.org
Date: Tuesday, November 20, 2012, 6:04 PM
Am 20.11.2012 23:49, schrieb Alfred
Perlstein:
On 11/20/12 2:42
Jack,
On Tue, Nov 20, 2012 at 09:19:54AM -0800, Jack Vogel wrote:
J> > I'd suggest the following code:
J> >
J> > if (m)
J> > drbr_enqueue(ifp, txr->br, m);
J> > err = igb_mq_start_locked(ifp, txr, NULL);
J> >
J> > Which eventually leads us
On 21.11.2012 03:16, khatfi...@socllc.net wrote:
I may be misstating.
Specifically under high burst floods either routed or being dropped by pf we
would see the system
go unresponsive to user-level applications / SSH for example.
The system would still function but it was inaccessible. To clar
Something that has popped up a few times, even recently, is breaking
out of an RX loop after you service a number of frames.
During stupidly high levels of RX, you may find the NIC happily
receiving frames faster than you can service the RX queue. If this
occurs, you could end up just plain being
21 matches
Mail list logo
