--- On Wed, 11/21/12, Adrian Chadd wrote:
> From: Adrian Chadd
> Subject: Re: FreeBSD boxes as a 'router'...
> To: "Andre Oppermann"
> Cc: "Barney Cordoba" , "Jim Thompson"
> , "Alfred Perlstein" , khatfi...@socllc.net,
>
On 21 November 2012 00:30, Andre Oppermann wrote:
> On 21.11.2012 08:55, Adrian Chadd wrote:
>>
>> Something that has popped up a few times, even recently, is breaking
>> out of an RX loop after you service a number of frames.
>
> That is what I basically described.
Right, and this can be done ri
--- On Wed, 11/21/12, John Fretby wrote:
> From: John Fretby
> Subject: Re: FreeBSD boxes as a 'router'...
> To: "Victor Balada Diaz"
> Cc: freebsd-...@freebsd.org
> Date: Wednesday, November 21, 2012, 11:40 AM
> On 21 November 2012 14:57, Victor
> Ba
On 21.11.2012 09:53, Luigi Rizzo wrote:
On Wed, Nov 21, 2012 at 12:36 AM, Andre Oppermann wrote:
On 21.11.2012 09:04, Luigi Rizzo wrote:
The only adjustment i'd suggest to your scheme, if possible, is to add
some control (as it existed in the old polling architecture) to make sure
that users
On Wed, Nov 21, 2012 at 12:36 AM, Andre Oppermann wrote:
> On 21.11.2012 09:04, Luigi Rizzo wrote:
>
>> On Tue, Nov 20, 2012 at 11:32 PM, Andre Oppermann
>> wrote:
>>
>>> ...
>>
>> very cool. this seems similar to NAPI.
>>
>
> I've heard about NAPI but haven't looked at it. So I'm not sure how
On 21.11.2012 09:04, Luigi Rizzo wrote:
On Tue, Nov 20, 2012 at 11:32 PM, Andre Oppermann wrote:
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-le
On 21.11.2012 08:55, Adrian Chadd wrote:
Something that has popped up a few times, even recently, is breaking
out of an RX loop after you service a number of frames.
That is what I basically described.
During stupidly high levels of RX, you may find the NIC happily
receiving frames faster tha
On Tue, Nov 20, 2012 at 11:32 PM, Andre Oppermann wrote:
> 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
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
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
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
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
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
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
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
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 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
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
--- 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
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
you're doing exactly the same
thingas polling without the overheard.
You're comparing polling to random tuning. Which is why I say that anyone
who recommends polling doesn't really understand what they're doing.
--- On Tue, 11/20/12, Jim Thompson wrote:
From: Jim Thompson
Subje
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
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
s
the same effect without having to have hacked code running in your driver.
--- On Tue, 11/20/12, khatfi...@socllc.net wrote:
> From: khatfi...@socllc.net
> Subject: Re: FreeBSD boxes as a 'router'...
> To: "Victor Balada Diaz"
> Cc: "freebsd-...@f
24 matches
Mail list logo