ALTQ patch for if_vlan.c

[Jon Simola]

On Wed, 5 Jan 2005 12:51:56 -0800, Brooks Davis
<brooks at one-eyed-alien.net> wrote:

> ALTQ makes no sense of virtual interfaces.  ALTQ works by providing
> fine-grained control of the dequeueing of packets on to the wire.  It's
> too early to do this when you're still in the virtual interface.

PF does not have any access to traffic on the vlan parent interface.
By my reading of the source, outbound traffic -> PF -> vlan ->
ether_output on the parent

This seems accurate as there are no packets leaving on the vlan parent
(em1 in my case):
bash-3.00# pfctl -vvs rules
@0 pass in quick on em1 all
  [ Evaluations: 749738    Packets: 0         Bytes: 0           States: 0     ]
@1 pass out quick on em1 all
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]



I've had this patch running for a few hours now and it certainly seems
to accomplish what I was looking to do (throttle DSL customers at my
router):

# pfctl -vs rules
pass out quick on vlan130 from any to <throttled_ips> keep state queue
throttle_130
  [ Evaluations: 249230    Packets: 6552      Bytes: 2443357     States: 554   ]

# pfctl -vs queue
queue  throttle_130 bandwidth 64Kb cbq( red )
  [ pkts:       1062  bytes:     348272  dropped pkts:   1588 bytes: 870884 ]
  [ qlength:  18/ 50  borrows:      0  suspends:    105 ]
  [ measured:    23.2 packets/s, 55.08Kb/s ]


> You can tag packets appropiratly at this point, but the actual ALTQ queue
> needs to be on a physical interface.

I don't see any way to accomplish this, and my experimenting has been
in vain until I patched ALTQ into if_vlan.

> FYI, spl*() funtions are all no-ops now.  We just have them around to
> remind us that we need to lock certain functions and to document what
> was protected before.

Thanks, good to know. I'm learning a lot about the kernel as I go.