by default, and can be enabled by adding the SOSEND_LOAN option to your
kernel config. The SOSEND_COUNTERS option can be used to provide some
instrumentation.
Use of this option, combined with an application that does large enough
writes, gets us zero-copy on the TCP and UDP transmit path.
userlevel; this is necessary due to the 601, unlike other 6xx, having
no concept of separated Valid_user vs. Valid_supervisor for BATs.
* When crossing the kernel/userlevel boundary, have platform-provided
hooks set up the two fixed BAT entries, and possibly additional
segment registers to redeem the 601's BAT limitations.
Both of the above are only built if the $MACHINE provides these hooks,
sparing others the pain.
transmit and receive descriptor rings is limited to 256 descriptors.
So, set the if_snd queue length to 256 to let the upper layers queue
lots of packets, and let the driver handle up to 32 of them at a time.
(We should probably make this change to most Ethernet drivers, since
it actually saves some resources.)
* Increase the number of Tx DMA segments from 8 to 16.
* Clean up the way we count "how many times did I get a packet with N
DMA segments".
* Add a missing htole32() in wm_tx_cksum().
* Don't set both RS and RPS in the last Tx descriptor of a packet; just
use RS.
* Add some more information to the watchdog message.
so that they're more useful for arbitrary types of external storage:
* Add an "mbuf *" argument to (*ext_free)(). If non-NULL, (*ext_free)()
is expected to free the mbuf itself. This allows (*ext_free)() to use
the mbuf for bookkeeping (e.g. deferring the work to a helper thread).
If the "mbuf *" argument is NULL, we are assumed to be in a context
which is safe for performing the destructor operation *now*.
* Adjust MEXTREMOVE() and MFREE() routines for above change.
* Update "ade" and "ti" drivers for new semantics.
eliminate a race where another processor could grab the outgoing
process before we were done saving our state into it, with predictable
results.
Bug spotted on i386 by Frank van der Linden <fvdl@wasabisystems.com>.
It is unclear if this realy is needed and if, on which type of cards. I
haven't run accross a card that needs it yet. This may have been just
a copy & pasto from the ISAC interrupt handler carried over to IPAC.
