Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5
Just as a data point - disable preemption and try again?
And run 4BSD + no preemption, try again?
Adrian
On 30 August 2012 22:50, Eugene Grosbein wrote:
> 31.08.2012 12:19, Eugene Grosbein пишет:
>
>> With HEAD driver, for same test LA pikes to 8 and higher and it takes up to
>> 10 seconds
>> for userland applications like shell or screen(1) to respond to physical
>> console events:
>>
>> last pid: 1335; load averages: 8.27, 4.05, 2.04up 0+00:14:21
>> 23:31:18
>> 97 processes: 2 running, 83 sleeping, 12 waiting
>> CPU: 0.1% user, 0.0% nice, 55.7% system, 43.6% interrupt, 0.6% idle
>> Mem: 40M Active, 21M Inact, 175M Wired, 2512K Cache, 109M Buf, 749M Free
>> Swap:
>>
>> PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND
>>12 root -16- 0K 8K sleep1:12 44.87% ng_queue
>>11 root -28- 0K96K WAIT 1:45 35.60% intr{swi5: +}
>>11 root -44- 0K96K WAIT 1:03 18.80% intr{swi1:
>> netisr 0}
>>10 root 171 ki31 0K 8K RUN 6:34 0.39% idle
>>13 root -16- 0K 8K -0:07 0.10% yarrow
>
> Not very representative screenshot; in fact, interrupt rate is at 90-100%
> level
> most of time for both of old and new vr(4) drivers during test and
> that's the reason of spiking Load Average.
>
> Eugene Grosbein
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5
31.08.2012 12:19, Eugene Grosbein пишет:
> With HEAD driver, for same test LA pikes to 8 and higher and it takes up to
> 10 seconds
> for userland applications like shell or screen(1) to respond to physical
> console events:
>
> last pid: 1335; load averages: 8.27, 4.05, 2.04up 0+00:14:21
> 23:31:18
> 97 processes: 2 running, 83 sleeping, 12 waiting
> CPU: 0.1% user, 0.0% nice, 55.7% system, 43.6% interrupt, 0.6% idle
> Mem: 40M Active, 21M Inact, 175M Wired, 2512K Cache, 109M Buf, 749M Free
> Swap:
>
> PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND
>12 root -16- 0K 8K sleep1:12 44.87% ng_queue
>11 root -28- 0K96K WAIT 1:45 35.60% intr{swi5: +}
>11 root -44- 0K96K WAIT 1:03 18.80% intr{swi1:
> netisr 0}
>10 root 171 ki31 0K 8K RUN 6:34 0.39% idle
>13 root -16- 0K 8K -0:07 0.10% yarrow
Not very representative screenshot; in fact, interrupt rate is at 90-100% level
most of time for both of old and new vr(4) drivers during test and
that's the reason of spiking Load Average.
Eugene Grosbein
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
vr(4) troubles for AMD Geode CS5536 chipset
In previous letter I've described my attempts to try vr(4) from HEAD. Now I'd like to explain why I've tried it. The problem is that stock vr(4) from 8.3-STABLE/i386 has serious issues for my system. I have home router with two vr interfaces, vr0 is for LAN (IPoE) and vr1 is for WAN (PPPoE/mpd). Presently, every day my WAN vr interface stops running correctly: sometimes it stops receiving all packets - tcpdump shows none of them. Sometimes, it receives some but with great delay - up to 10 seconds (not miliseconds) and even more. tcpdump shows that delay occurs on receive path. Sometimes, it even rearranges packets - tcpdump shows that some incoming ICMP echo requests with lower sequence numbers come in later that already answered higher-numbered requests. ifconfig vr1 down/up revives interface completely until next morning. sysctl net.inet.ip.fw.enable=0 does not solve the problem. I have control over WAN switching/routing network and may assure it runs just fine. However, I can't guarantee it has no "soft" anomalies like short storms or some silly broadcasts. I've tried to make incoming flood with ng_source(4) generated UDP flood at 100M rate for 60 seconds and failed to reproduce the problem artificially. I've tried to move WAN from vr1 to vr0 and the problem has moved to vr0 too. My LAN has very little traffic and corresponding vr interface exhibits no problems. This router also routinely runs transmission (torrent client from ports) serving torrents from USB-attached HDD making severe CPU load, so I suspect the problem may be related with CPU load. I've also checked mbuf/mbuf clusters usage and they are all right: # netstat -m 1539/2076/3615 mbufs in use (current/cache/total) 1200/1278/2478/65536 mbuf clusters in use (current/cache/total/max) 1200/306 mbuf+clusters out of packet secondary zone in use (current/cache) 318/181/499/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 4056K/3799K/7855K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/4/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines # vmstat -z | egrep -i 'ITEM|mbuf' ITEM SIZE LIMIT USED FREE REQUESTS FAILURES mbuf_packet: 256,0, 1429, 77, 112854470,0 mbuf: 256,0, 489, 1620, 369073316,0 mbuf_cluster:2048,65536, 1506, 604, 5401864,0 mbuf_jumbo_page: 4096,12800, 469, 158, 8306777,0 mbuf_jumbo_9k: 9216, 6400,0,0,0,0 mbuf_jumbo_16k: 16384, 3200,0,0,0,0 mbuf_ext_refcnt:4,0,0,0,0,0 NetGraph items:36, 4130,1, 117, 263123,0 NetGraph data items: 36, 531,0, 295, 106663377,0 While ifconfig vr1 down/up solves the problem completely (for some long time), taking link down/up using switch solves it "in half" - huge packet delays disappear and turn to 25% packet loss happening in regular short intervals, once a second of like. ifconfig down/up clears this mess too. Please help me to debug this, it's pretty annoying. I had a hope new vr(4) driver would help but it takes my system down under average load and is unusable. Here is start of dmesg.boot: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.3-STABLE #1: Wed Aug 29 22:49:45 NOVT 2012 r...@grosbein.pp.ru:/usr/local/obj/nanobsd.gw/i386/usr/local/src/sys/GW i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Family = 5 Model = a Stepping = 2 Features=0x88a93d AMD Features=0xc040 real memory = 1065025536 (1015 MB) avail memory = 1032929280 (985 MB) K6-family MTRR support enabled (2 registers) I must also note that this system runs with ACPI disabled in /boot/loader.conf: hint.acpi.0.disabled=1 Otherwise, its timekeeping becomes broken. Eugene Gtosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5
01.09.2012 01:07, YongHyeon PYUN пишет:
> It would be interesting to know whether there is any difference
> before/after taskq change made in r235334. I was told that taskq
> conversion for vr(4) resulted in better performance but I think
> taskq shall add more burden on slow hardware.
> Pre-r235334 interrupt handler still has issues since it wouldn't
> exit interrupt handler if there are any pending interrupts.
> It shall consume most of its CPU cycles in the interrupt handler
> under extreme network load. If pre-r235334 shows better result,
> you are probably able to implement interrupt mitigation by using
> VT6102/VT6105's timer interrupt. I guess some frames would be lost
> with the interrupt mitigation under high network load but other
> part of kernel would have more chance to run important tasks.
> Anyway, vr(4) controllers wouldn't be one of best choice for slow
> machines due to DMA alignment limitation and driver assisted
> padding requirement.
I also have AMD Geode LX8-based system having two on-board vr(4)
interfaces. I've just tried it with vr(4) driver from HEAD
built as module for my 8.3-STABLE/i386.
It builds just fine with minor change:
--- if_vr.c.orig2012-08-29 23:36:05.0 +0700
+++ if_vr.c 2012-08-29 22:51:01.0 +0700
@@ -2176,7 +2176,7 @@
VR_LOCK(sc);
mii = device_get_softc(sc->vr_miibus);
LIST_FOREACH(miisc, &mii->mii_phys, mii_list)
- PHY_RESET(miisc);
+ mii_phy_reset(miisc);
sc->vr_flags &= ~(VR_F_LINK | VR_F_TXPAUSE);
error = mii_mediachg(mii);
VR_UNLOCK(sc);
dmesg says:
vr0: port 0xe000-0xe0ff mem
0xef024000-0xef0240ff irq 10 at device 12.0 on pci0
vr0: Quirks: 0x0
vr0: Revision: 0x86
miibus0: on vr0
ukphy0: PHY 1 on miibus0
ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
vr0: Ethernet address: 00:10:f3:13:72:c6
vr0: [ITHREAD]
vr1: port 0xe400-0xe4ff mem
0xef025000-0xef0250ff irq 11 at device 13.0 on pci0
vr1: Quirks: 0x0
vr1: Revision: 0x86
miibus1: on vr1
ukphy1: PHY 1 on miibus1
ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
vr1: Ethernet address: 00:10:f3:13:72:c7
vr1: [ITHREAD]
This is industrial Nexcom NICE-3120-LX8 fanless PC system used as home router,
the only miniPCI expansion slot is occupied with ath0 WiFi card.
http://www.orbitmicro.com/global/system-4423.html
I have to say that HEAD driver runs MUCH worse. With stock 8.3 driver
I have same 3.35MByte/s one-thread http transfer through this system
but LA=1.7 only and userland is pretty responsive. top(1) shows:
last pid: 29696; load averages: 1.70, 1.08, 0.88up 2+00:11:31
22:21:46
94 processes: 2 running, 78 sleeping, 14 waiting
CPU: 7.7% user, 0.0% nice, 0.0% system, 15.4% interrupt, 76.9% idle
Mem: 51M Active, 671M Inact, 188M Wired, 18M Cache, 110M Buf, 60M Free
Swap:
PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND
11 root -68- 0K 112K WAIT 235:11 51.56% intr{irq11: vr1}
10 root 171 ki31 0K 8K RUN 24.4H 31.15% idle
11 root -44- 0K 112K WAIT 0:51 9.38% intr{swi1:
netisr 0}
11 root -68- 0K 112K WAIT 0:30 6.40% intr{irq10: vr0}
29688 root 440 3628K 1708K RUN 0:00 0.10% top
With HEAD driver, for same test LA pikes to 8 and higher and it takes up to 10
seconds
for userland applications like shell or screen(1) to respond to physical
console events:
last pid: 1335; load averages: 8.27, 4.05, 2.04up 0+00:14:21
23:31:18
97 processes: 2 running, 83 sleeping, 12 waiting
CPU: 0.1% user, 0.0% nice, 55.7% system, 43.6% interrupt, 0.6% idle
Mem: 40M Active, 21M Inact, 175M Wired, 2512K Cache, 109M Buf, 749M Free
Swap:
PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND
12 root -16- 0K 8K sleep1:12 44.87% ng_queue
11 root -28- 0K96K WAIT 1:45 35.60% intr{swi5: +}
11 root -44- 0K96K WAIT 1:03 18.80% intr{swi1:
netisr 0}
10 root 171 ki31 0K 8K RUN 6:34 0.39% idle
13 root -16- 0K 8K -0:07 0.10% yarrow
That's with direct NETISR mode, indirect mode makes it only worse (LA is higher
for both drivers, up to 4.5 for old one and up to 9+ for new).
I ran tests with same custom kernel, loading/unloading old/new drivers as
modules
without reboot. Schedules is default SCHED_ULE.
Another note: I run mpd/PPPoE/ng0 over vr1 and http transfer were through ng0.
Eugene Grosbein
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?)
On Thu, Aug 30, 2012 at 01:11:58PM +0400, Lev Serebryakov wrote: > Hello, Ian. > You wrote 30 августа 2012 г., 10:23:56: > > >> Yep, I'll collapse my two-rule chains in one rule. > IS> I guess if the issue persists, we may need to see more of your ruleset. > Not a problem at all, here it is: > http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw > > IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface > IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expect > Yep. I didn't see it. My question is, really: why vr1 (my physical > interface, used to connect to my ISP) takes 50%+ of CPU when traffic > is only 40mbit/s down and about 20mbit/s up (with many connections)? I > was afraid, that all PPPoE traffic is inspected by ipfw and it causes > additional CPU load. It would be interesting to know whether there is any difference before/after taskq change made in r235334. I was told that taskq conversion for vr(4) resulted in better performance but I think taskq shall add more burden on slow hardware. Pre-r235334 interrupt handler still has issues since it wouldn't exit interrupt handler if there are any pending interrupts. It shall consume most of its CPU cycles in the interrupt handler under extreme network load. If pre-r235334 shows better result, you are probably able to implement interrupt mitigation by using VT6102/VT6105's timer interrupt. I guess some frames would be lost with the interrupt mitigation under high network load but other part of kernel would have more chance to run important tasks. Anyway, vr(4) controllers wouldn't be one of best choice for slow machines due to DMA alignment limitation and driver assisted padding requirement. > > Yes, it is only 500Mhz Geode LX, but it is only 40 mbit/s and > 4.5Kpps in both directions, nothing like full 100Mbit or more, and > I've learned "empirical" rule/heuristics about 1Gbit(!) per 1Ghz(!) > for softrouters, So, theoretically, 40mbit should not be a problem at > all for this hardware. > > And now I have not-working WiFi (this box is also AP) when wired > traffic is high (wifi speed drops down to 100KB/s from 2.5-3MB/s > without wired traffic), userland freezes under load (very bad with > ULE, better with 4BSD), and inability to pass through 40Mbit in both > directions simultaneously. > > -- > // Black Lion AKA Lev Serebryakov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bridging VLAN interfaces and STP
On Mon, Aug 27, 2012 at 7:45 AM, Dustin J. Mitchell wrote: > On Mon, Aug 27, 2012 at 5:49 AM, Peter Jeremy wrote: >> On 2012-Aug-26 08:12:51 -0400, "Dustin J. Mitchell" >> wrote: >>>On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell >>>wrote: Hey folks. I'm trying to set up a system with one 802.1q-tagged upstream, and a few untagged interfaces. So I'd like to bridge the vlan(4) interfaces on vr1 to specific other interfaces. >> >> Can you provide ifconfig output covering all the relevant interfaces. > > Sure: Peter, or anyone else -- any thoughts on this issue? Dustin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?)
On Thu, Aug 30, 2012 at 03:32:25PM -0500, Adam Vande More wrote: > On Thu, Aug 30, 2012 at 4:11 AM, Lev Serebryakov wrote: > > > Hello, Ian. > > You wrote 30 августа 2012 г., 10:23:56: > > > > >> Yep, I'll collapse my two-rule chains in one rule. > > IS> I guess if the issue persists, we may need to see more of your ruleset. > > Not a problem at all, here it is: > > http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw > > > > IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface > > IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expect > > Yep. I didn't see it. My question is, really: why vr1 (my physical > > interface, used to connect to my ISP) takes 50%+ of CPU when traffic > > is only 40mbit/s down and about 20mbit/s up (with many connections)? > > > Have you taken this into account from vr(4)? > > BUGS > The vr driver always copies transmit mbuf chains into longword-aligned > buffers prior to transmission in order to pacify the Rhine chips. If > buffers are not aligned correctly, the chip will round the supplied > buffer address and begin DMAing from the wrong location. This buffer > copying impairs transmit performance on slower systems but cannot be > avoided. On faster machines (e.g. a Pentium II), the performance > impact > is much less noticeable. I'm not sure what controller is used in Geode LX but newer vr(4) controllers such as VT6105/VT6105M do not have such DMA alignment limitation of TX buffer. vr(4) selectively enables software workaround based on controller revision. Manual software padding for short frames(< 60 bytes) is still required for all VIA fast ethernet controllers though. vr_attach() will show what quirks are activated so you would be able to tell whether your controller has TX DMA buffer alignment limitation or not. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
lagg failover issue
Hi, I'm using following devices: bge0 - NetLink BCM57780 Gigabit Ethernet PCIe ndis0 - BCM43225 802.11b/g/n As far as I've tested it, each of them work fine for itself. I want to aggregate them using lagg in failover mode as explained here[1][2]. But when I remove the wire (wireless connection is established), I can't put any traffic through lagg0. What might be the problem? Can you give me some hints on how to debug this lagg-issue further? Regards, kaltheat [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html Example 32-3. Failover Mode Between Wired and Wireless Interfaces [2] http://www.freebsd.org/cgi/man.cgi?query=lagg#EXAMPLES Second example ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?)
On Thu, Aug 30, 2012 at 03:32:25PM -0500, Adam Vande More wrote: > On Thu, Aug 30, 2012 at 4:11 AM, Lev Serebryakov wrote: > > > Hello, Ian. > > You wrote 30 ??? 2012 ?., 10:23:56: > > > > >> Yep, I'll collapse my two-rule chains in one rule. > > IS> I guess if the issue persists, we may need to see more of your ruleset. > > Not a problem at all, here it is: > > http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw > > > > IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface > > IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expect > > Yep. I didn't see it. My question is, really: why vr1 (my physical > > interface, used to connect to my ISP) takes 50%+ of CPU when traffic > > is only 40mbit/s down and about 20mbit/s up (with many connections)? > > > Have you taken this into account from vr(4)? I was indeed going to mention something like this. Old/slow machines often have very low memory bandwidth, so the rule 1GHz<->1 Gbit/s does not really apply. cheers luigi > BUGS > The vr driver always copies transmit mbuf chains into longword-aligned > buffers prior to transmission in order to pacify the Rhine chips. If > buffers are not aligned correctly, the chip will round the supplied > buffer address and begin DMAing from the wrong location. This buffer > copying impairs transmit performance on slower systems but cannot be > avoided. On faster machines (e.g. a Pentium II), the performance > impact > is much less noticeable. > -- > Adam Vande More > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?
On Wed, Aug 29, 2012 at 08:01:50AM -0700, Michael Sierchio wrote: > On Wed, Aug 29, 2012 at 8:01 AM, Michael Sierchio wrote: > > > ip from any to any in recv vr0 > > "any" here is also not appropriate... it is just sintactic sugar, "from any to any" corresponds is just printed by default to make the rule look like the 'old style' (pre-2003) ipfw syntax, but otherwise has zero cost at runtime. cheers luigi > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?)
On Thu, Aug 30, 2012 at 4:11 AM, Lev Serebryakov wrote: > Hello, Ian. > You wrote 30 августа 2012 г., 10:23:56: > > >> Yep, I'll collapse my two-rule chains in one rule. > IS> I guess if the issue persists, we may need to see more of your ruleset. > Not a problem at all, here it is: > http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw > > IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface > IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expect > Yep. I didn't see it. My question is, really: why vr1 (my physical > interface, used to connect to my ISP) takes 50%+ of CPU when traffic > is only 40mbit/s down and about 20mbit/s up (with many connections)? Have you taken this into account from vr(4)? BUGS The vr driver always copies transmit mbuf chains into longword-aligned buffers prior to transmission in order to pacify the Rhine chips. If buffers are not aligned correctly, the chip will round the supplied buffer address and begin DMAing from the wrong location. This buffer copying impairs transmit performance on slower systems but cannot be avoided. On faster machines (e.g. a Pentium II), the performance impact is much less noticeable. -- Adam Vande More ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?)
Hello, Adrian. You wrote 30 августа 2012 г., 23:01:12: >> Yes, it is only 500Mhz Geode LX, but it is only 40 mbit/s and >> 4.5Kpps in both directions, nothing like full 100Mbit or more, and >> I've learned "empirical" rule/heuristics about 1Gbit(!) per 1Ghz(!) >> for softrouters, So, theoretically, 40mbit should not be a problem at >> all for this hardware. AC> It honestly shouldn't be that bad, but without dumping a bunch of AC> effort into profiling (even if it's just sampled profiling via gprof) Is it possible to use gprof with kernel? As here is no userland processes involved: PPPoE is porcessed by netgrpah, routing & ipfw is kernel stuff too... AC> I won't know whether that's "good" or not. >> And now I have not-working WiFi (this box is also AP) when wired >> traffic is high (wifi speed drops down to 100KB/s from 2.5-3MB/s >> without wired traffic), userland freezes under load (very bad with >> ULE, better with 4BSD), and inability to pass through 40Mbit in both >> directions simultaneously. AC> Hm. What about disabling preemption and see if that helps? I still AC> haven't fully debugged/diagnosed why preemption acts weirdly on my AC> mips24k boards (which is why all the mips24k Atheros SoC's have 4BSD + AC> no PREEMPT.) I'll try it. Also, I noticed, that with any scheduler it could not route 40Mbit in BOTH directions simultaneously, and downstream has priority. When there is no much of downstream, it upload at 40-45Mibt/s, and when downstream is 40-45Mibt/s upstream could be only about 20Mbit/s. -- // Black Lion AKA Lev Serebryakov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?)
On 30 August 2012 02:11, Lev Serebryakov wrote: > Yes, it is only 500Mhz Geode LX, but it is only 40 mbit/s and > 4.5Kpps in both directions, nothing like full 100Mbit or more, and > I've learned "empirical" rule/heuristics about 1Gbit(!) per 1Ghz(!) > for softrouters, So, theoretically, 40mbit should not be a problem at > all for this hardware. It honestly shouldn't be that bad, but without dumping a bunch of effort into profiling (even if it's just sampled profiling via gprof) I won't know whether that's "good" or not. > And now I have not-working WiFi (this box is also AP) when wired > traffic is high (wifi speed drops down to 100KB/s from 2.5-3MB/s > without wired traffic), userland freezes under load (very bad with > ULE, better with 4BSD), and inability to pass through 40Mbit in both > directions simultaneously. Hm. What about disabling preemption and see if that helps? I still haven't fully debugged/diagnosed why preemption acts weirdly on my mips24k boards (which is why all the mips24k Atheros SoC's have 4BSD + no PREEMPT.) Adrian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[CFT] if_transmit method for if_bridge(4)
Hi,
I have a patch laying around, that makes if_bridge(4) utilize
if_transmit method. That should improvide performance.
I'd appreciate if someone who actually do use if_bridge(4) tests
this patch.
--
Totus tuus, Glebius.
Index: if_bridge.c
===
--- if_bridge.c (revision 239904)
+++ if_bridge.c (working copy)
@@ -245,11 +245,12 @@
static void bridge_init(void *);
static void bridge_dummynet(struct mbuf *, struct ifnet *);
static void bridge_stop(struct ifnet *, int);
-static void bridge_start(struct ifnet *);
+static int bridge_transmit(struct ifnet *, struct mbuf *);
+static void bridge_qflush(struct ifnet *);
static struct mbuf *bridge_input(struct ifnet *, struct mbuf *);
static int bridge_output(struct ifnet *, struct mbuf *, struct sockaddr *,
struct rtentry *);
-static void bridge_enqueue(struct bridge_softc *, struct ifnet *,
+static int bridge_enqueue(struct bridge_softc *, struct ifnet *,
struct mbuf *);
static void bridge_rtdelete(struct bridge_softc *, struct ifnet *ifp, int);
@@ -600,12 +601,10 @@
if_initname(ifp, ifc->ifc_name, unit);
ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
ifp->if_ioctl = bridge_ioctl;
- ifp->if_start = bridge_start;
+ ifp->if_transmit = bridge_transmit;
+ ifp->if_qflush = bridge_qflush;
ifp->if_init = bridge_init;
ifp->if_type = IFT_BRIDGE;
- IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen);
- ifp->if_snd.ifq_drv_maxlen = ifqmaxlen;
- IFQ_SET_READY(&ifp->if_snd);
/*
* Generate an ethernet address with a locally administered address.
@@ -1780,7 +1779,7 @@
* Enqueue a packet on a bridge member interface.
*
*/
-static void
+static int
bridge_enqueue(struct bridge_softc *sc, struct ifnet *dst_ifp, struct mbuf *m)
{
int len, err = 0;
@@ -1823,6 +1822,8 @@
if (mflags & M_MCAST)
sc->sc_ifp->if_omcasts++;
}
+
+ return (err);
}
/*
@@ -1981,44 +1982,43 @@
}
/*
- * bridge_start:
+ * bridge_transmit:
*
- * Start output on a bridge.
+ * Do output on a bridge.
*
*/
-static void
-bridge_start(struct ifnet *ifp)
+static int
+bridge_transmit(struct ifnet *ifp, struct mbuf *m)
{
struct bridge_softc *sc;
- struct mbuf *m;
- struct ether_header *eh;
- struct ifnet *dst_if;
+ int error = 0;
sc = ifp->if_softc;
- ifp->if_drv_flags |= IFF_DRV_OACTIVE;
- for (;;) {
- IFQ_DEQUEUE(&ifp->if_snd, m);
- if (m == 0)
- break;
- ETHER_BPF_MTAP(ifp, m);
+ ETHER_BPF_MTAP(ifp, m);
+
+ BRIDGE_LOCK(sc);
+ if ((m->m_flags & (M_BCAST|M_MCAST)) == 0) {
+ struct ether_header *eh;
+ struct ifnet *dst_if;
+
eh = mtod(m, struct ether_header *);
- dst_if = NULL;
+ dst_if = bridge_rtlookup(sc, eh->ether_dhost, 1);
+ BRIDGE_UNLOCK(sc);
+ error = bridge_enqueue(sc, dst_if, m);
+ } else
+ bridge_broadcast(sc, ifp, m, 0);
- BRIDGE_LOCK(sc);
- if ((m->m_flags & (M_BCAST|M_MCAST)) == 0) {
- dst_if = bridge_rtlookup(sc, eh->ether_dhost, 1);
- }
+ return (error);
+}
- if (dst_if == NULL)
- bridge_broadcast(sc, ifp, m, 0);
- else {
- BRIDGE_UNLOCK(sc);
- bridge_enqueue(sc, dst_if, m);
- }
- }
- ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
+/*
+ * The ifp->if_qflush entry point for if_bridge(4) is no-op.
+ */
+static void
+bridge_qflush(struct ifnet *ifp __unused)
+{
}
/*
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: witness warning in arp processing
On Wednesday, August 29, 2012 4:45:29 pm Navdeep Parhar wrote:
> On 08/29/12 10:30, Vijay Singh wrote:
> > All, I am seeing this warning on my 8.2 based system.
> >
> > taskqueue_drain with the following non-sleepable locks held:
> > exclusive rw lle (lle) r = 0 (0xff0014dc9110) locked @
> > sys/netinet/in.c:1760
> > KDB: stack backtrace:
> > kdb_backtrace() at kdb_backtrace+0x3e
> > _witness_debugger() at _witness_debugger+0x24
> > witness_warn() at witness_warn+0x402
> > taskqueue_drain() at taskqueue_drain+0x36
> > cancel_delayed_work() at cancel_delayed_work+0x56
> > set_timeout() at set_timeout+0x18
> > netevent_callback() at netevent_callback+0x29
> > _handle_arp_update_event() at _handle_arp_update_event+0x31
> > in_arpinput() at in_arpinput+0xe92
> > arpintr() at arpintr+0x255
> > netisr_dispatch_src() at netisr_dispatch_src+0x14a
> > netisr_dispatch() at netisr_dispatch+0x20
> > ether_demux() at ether_demux+0x281
> > ether_input_internal() at ether_input_internal+0x60c
> > ether_nh_input() at ether_nh_input+0x1d
> > netisr_dispatch_src() at netisr_dispatch_src+0x14a
> > netisr_dispatch() at netisr_dispatch+0x20
> > ether_input() at ether_input+0xef
> > lem_rxeof() at lem_rxeof+0x6ee
> > lem_handle_rxtx() at lem_handle_rxtx+0x4f
> > taskqueue_run_locked() at taskqueue_run_locked+0x145
> > taskqueue_thread_loop() at taskqueue_thread_loop+0x73
> > fork_exit() at fork_exit+0x180
> > fork_trampoline() at fork_trampoline+0xe
> >
> > Is this a known issue? Has it been fixed?
>
> This is a bug in the OFED code. The event handler it registers for the
> ARP update is not supposed to do anything that could sleep..
You could try this:
Index: ofed/include/linux/workqueue.h
===
--- ofed/include/linux/workqueue.h (revision 239905)
+++ ofed/include/linux/workqueue.h (working copy)
@@ -184,9 +184,9 @@ cancel_delayed_work(struct delayed_work *work)
{
callout_stop(&work->timer);
- if (work->work.taskqueue &&
- taskqueue_cancel(work->work.taskqueue, &work->work.work_task, NULL))
- taskqueue_drain(work->work.taskqueue, &work->work.work_task);
+ if (work->work.taskqueue)
+ taskqueue_cancel(work->work.taskqueue, &work->work.work_task,
+ NULL);
return 0;
}
This changes the code to match the comment above cancel_delayed_work()
and should fix this warning:
/*
* This may leave work running on another CPU as it does on Linux.
*/
static inline int
cancel_delayed_work(struct delayed_work *work)
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/164475: [gre] gre misses RUNNING flag after a reboot
The following reply was made to PR kern/164475; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-follo...@freebsd.org Cc: Subject: Re: kern/164475: [gre] gre misses RUNNING flag after a reboot Date: Thu, 30 Aug 2012 15:30:04 +0600 Guys, it's still there. FreeBSD alix-panicbox 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2: Mon Jul 23 03:02:45 YEKT 2012 e...@zombie.hq.norma.perm.ru:/usr/obj/nanobsd.alix/usr/src/sys/ALIX i386 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?)
Hello, Ian. You wrote 30 августа 2012 г., 10:23:56: >> Yep, I'll collapse my two-rule chains in one rule. IS> I guess if the issue persists, we may need to see more of your ruleset. Not a problem at all, here it is: http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expect Yep. I didn't see it. My question is, really: why vr1 (my physical interface, used to connect to my ISP) takes 50%+ of CPU when traffic is only 40mbit/s down and about 20mbit/s up (with many connections)? I was afraid, that all PPPoE traffic is inspected by ipfw and it causes additional CPU load. Yes, it is only 500Mhz Geode LX, but it is only 40 mbit/s and 4.5Kpps in both directions, nothing like full 100Mbit or more, and I've learned "empirical" rule/heuristics about 1Gbit(!) per 1Ghz(!) for softrouters, So, theoretically, 40mbit should not be a problem at all for this hardware. And now I have not-working WiFi (this box is also AP) when wired traffic is high (wifi speed drops down to 100KB/s from 2.5-3MB/s without wired traffic), userland freezes under load (very bad with ULE, better with 4BSD), and inability to pass through 40Mbit in both directions simultaneously. -- // Black Lion AKA Lev Serebryakov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: sorele() and ACCEPT_LOCK()
On 30 August 2012 04:23, Vijay Singh wrote:
> Is there any reason why sorele() needs the accept lock to be held?
>
> 231 #define sorele(so) do {
> \
> 232 ACCEPT_LOCK_ASSERT();
> \
> 233 SOCK_LOCK_ASSERT(so);
> \
> 234 if ((so)->so_count <= 0)
> \
> 235 panic("sorele");
> \
> 236 if (--(so)->so_count == 0)
> \
> 237 sofree(so);
> \
> 238 else {
> \
> 239 SOCK_UNLOCK(so);
> \
> 240 ACCEPT_UNLOCK();
> \
> 241 }
> \
> 242 } while (0)
sofree() needs accept lock to be held to operate on a qstate field.
sofree() callers cannot be changed to push accept lock acquisition into
sofree() because that would require to reacquire sock lock around accept
lock to take locks in order; this in turn opens race.
See r136682 for details.
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
