Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Jun 2008 23:12:25 -0400
From:      Paul <paul@gtcomm.net>
To:        Sepherosa Ziehau <sepherosa@gmail.com>
Cc:        freebsd-net@freebsd.org, Ingo Flaschberger <if@xip.at>, "Wilkinson, Alex" <alex.wilkinson@dsto.defence.gov.au>, "Support \(Rudy\)" <crapsh@monkeybrains.net>
Subject:   Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
Message-ID:  <4869A099.5070206@gtcomm.net>
In-Reply-To: <ea7b9c170806302005n2a66f592h2127f87a0ba2c6d2@mail.gmail.com>
References:  <4867420D.7090406@gtcomm.net>	 <200806301944.m5UJifJD081781@lava.sentex.ca>	 <20080701004346.GA3898@stlux503.dsto.defence.gov.au>	 <alpine.LFD.1.10.0807010257570.19444@filebunker.xip.at>	 <20080701010716.GF3898@stlux503.dsto.defence.gov.au>	 <alpine.LFD.1.10.0807010308320.19444@filebunker.xip.at>	 <486986D9.3000607@monkeybrains.net> <48699960.9070100@gtcomm.net> <ea7b9c170806302005n2a66f592h2127f87a0ba2c6d2@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I have been unable to even come close to livelocking the machine with 
the em driver interrupt moderation.
So that to me throws polling out the window.  I tried 8000hz with 
polling modified to allow 10000 burst and it makes no difference
in the amount of pps I can jam through.. It' seems to be limited by the 
routing path in the kernel more than anything else.

If a driver/hardware didn't support interrupt mitigation then it would 
definitely lock the machine.


Sepherosa Ziehau wrote:
> On 7/1/08, Paul <paul@gtcomm.net> wrote:
>   
>> All the NIC drivers in 7 pretty much use interrupt moderation so it can
>>     
>
> I am not quite sure whether em(4)'s RX interrupt moderation works as
> expected or not.  But, AFAIK, nfe(4) and re(4) does not have RX
> interrupt moderation.  Their TX interrupt moderation could be mimiced
> by using their hardware timer and disabling their TX interrupt.
>
> The lacking of RX im is difficult to handle, I could imagine following way:
> - During init, enable RX intr
> - When RX intr comes, disable RX intr and set up hardware timer intr
> - When timer intr comes and no RX happens, disable timer intr and enable RX intr
>
> Properly configured #RX desc and timer intr interval will be required
> to make sure that the RX desc collection could keep up with the
> hardware speed.  I used pure timer intr (8000Hz) on nfe(4) in dfly w/
> good result, i.e. TX/RX @linespeed without livelocking the system.
> The drawback of pure timer intr is that you waste extra cpu power,
> when there is nothing to process.
>
>   
>> never lock the machine anyway.. This effectively kills polling and it really
>> no longer has any use except to be able to have a fraction of the cpu set
>>     
>
> Oh?  Really? :]
>
> Best Regards,
> sephe
>
>   




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4869A099.5070206>