#
130384 |
|
12-Jun-2004 |
mlaier |
Add an additional queue which will be "owned by the driver". This allows to rig a PREPEND macro for ALTQ as the POLL/DEQUEUE semantic is very bad in terms of locking. We make this a full functional queue to allow "bulk dequeue" which will further reduce the locking overhead (for non-altq enabled devices). Drivers will access this via the following macros, which will show up in <net/if_var.h> once we expose ALTQ to the build:
IFQ_DRV_DEQUEUE(ifq, m) - takes a mbuf off the queue (driver queue first) IFQ_DRV_PREPEND(ifq, m) - pushes a mbuf back to the driver queue IFQ_DRV_PURGE(ifq) - drops all packets in both queues IFQ_DRV_IS_EMPTY(ifq) - checks for pending mbufs in either queue
One has to make sure that the first three are protected by a driver mutex. At the moment most network drivers still require Giant, so this is not an issue. Even those that have thier own mutex usually hold it in if_start and the like, so this requirement is almost always satisfied.
This evolved from a discussion with Andrew Gallatin.
|
#
130365 |
|
11-Jun-2004 |
mlaier |
Import parts of the ALTQ framework from latest KAME snapshot (which is up to HEAD at this point). This will not exactly live in a vendor branch, but have the vendor backing to make it easier to exchange diffs.
This will be followed by a diff which takes most of the .c files off the vendor branch in order to: - add locking - disable ALTQ3_COMPAT code (which is outdated and "un-lockable")
There is work in progress to refine the configuration API. Import this "as is" now to have more exposure time before 5-STABLE.
This is only the import, it will be some more days until you will actually be able to compile ALTQ support into your kernel so don't hold your breath. HEADUPs will be posted on current@ and net@ before this is actually enabled.
No-objection: re(scottl), core(rwatson)
|