FreeBSD network drivers using legacy interrupt wrappers are extremely slow

[kallisti5]

It has been observed that the marvel yukon driver is extremely slow. tqh reports that it may be a larger overall bug in the FreeBSD wrapper and how it handles legacy interrupt wrappers.

As I think I have seen the same thing on various network cards, lets get a common bug open for it.

I am compiling a list of drivers that use the legacy interrupt wrappers... then lets see if we can flesh out a pattern of bug reports for each affected driver.

[kallisti5]

Here are the results of my initial research:

Data was found by examining the calls to bus_setup_intr in each network driver and looking for two factors:

• NULL in the 4th argument
• the INTR_FAST flag passed to the 3rd argument

Based on function here:

​http://cgit.haiku-os.org/haiku/tree/src/libs/compat/freebsd_network/bus.c#n343

Legacy interrupts:

• 3com
• broadcom440x
• dec21xxx
• ipro100
• marvell_yukon
• rtl8139
• syskonnect
• via_rhine
• vt612x
• wlan/atheroswifi
• wlan/aironetwifi
• wlan/broadcom43xx
• wlan/iprowifi3945
• wlan/iprowifi2100
• wlan/ralink2860
• wlan/wavelanwifi
• wlan/marvell88w8363
• wlan/ralinkwifi
• wlan/iprowifi4965
• wlan/iprowifi2200

Not legacy interrupts:

• ar81xx
• atheros813x
• attansic_l1
• attansic_l2
• jmicron2x0
• nforce
• wlan/marvell88w8335

Could be either:

• broadcom570x
  • if (BGE_IS_5755_PLUS(sc) && sc->bge_flags & BGE_FLAG_MSI)? Not legacy
  • else? Legacy
• ipro1000
• pcnet
• rtl81xx

[kallisti5]

I plugged a rtl8139 pci card into my hrevr1alpha4-44608 system (which should be using legacy interrupts) and didn't see the reported slowdowns. I downloaded the Haiku disk image as well as linux kernel.

Local network ping times remained in the < 1ms range, and remote (google.com) ping times remained in the 30ms range.

[tqh]

Ah then it gets harder, perhaps check how interrupts are acknowledged/disabled by different drivers. It would be really good if people with slow network cards report what card they have.

It could be it is just a problem with i4965 and marvell yukon. Given that yukon does not use wlan code at all, it might be easier to try and see what's the problem there first. I don't have a marvell yukon so I can't do much. I do have a i4965 and it tops out at 100KB/s under Haiku, while on Linux it is at least >20 times faster. Pinging the router goes from <2ms to 1s if you start a download, but returns to <2ms if you stop the download. i4965 uses a lot of locking and do heavy handling in the int handler so I suspect lock contention. I think there is something to be learned by how FreeBSD does (MSI?) int handling, havn't got the time to look into it yet.

Btw have you checked that it is using the 8139 driver? IIRC some generations are more like 8169. You might also want to compare cpu usage.

[kallisti5]

I plan on doing some more testing here... but I've not been able to reproduce any issues with these legacy interrupt cards. (the 8139 I tested was using the 8139 driver as per listimage)

I'd say this issue may be limited to marvell_yukon given the lack of open issues for other cards in comment:2

Going to try and test a few more cards that use 'legacy interrupts' then close this.

[kallisti5]

I haven't seen this on any PCI network cards (i've tried 4-5 now)... this may be only something that is seen on laptop internal NIC's?

I have an old P4 laptop stashed away, let me pull it out, dust it off and try the latest R1A4 nightly on it.

[tqh]

Then maybe it isn't a problem. From lock usage info on i4965 I suspect it is, but might just be on my card / network / ...

See ​https://plus.google.com/u/0/116713839708821747722/posts/QpUzBRczywm for some info on my measurements.

[mmlr]

Replying to tqh:

Then maybe it isn't a problem. From lock usage info on i4965 I suspect it is, but might just be on my card / network / ...

I think the semaphore in question isn't used as a lock but as a signal. Basically the thread in question is always waiting on the semaphore unless there is an action to be taken (i.e. a task is added to the queue). So high wait times are to be expected here.

[kallisti5]

I should note, booting R1A4 anyboot from a CD on the Dell GX620 next to me resulted in the following (at least twice now)

• Deskbar frozen
• Running ifconfig from the terminal results in a frozen ifconfig process.

I ended up needing to reboot to get it moving again. Network cards are broadcom570x and 3com.

No network lag though when it's working.. when the above occurs i can't get out of the local machine.

[kallisti5]

Maybe the NetworkStatus app is locked somehow that is locking the Deskbar?

[kallisti5]

this seems like something too hard to fix pre-r1a4. closing as a solution was found for #8454

[lindausa0106]

Spam deleted