As discoverd by Adrian Close on tech@ (in "VLAN priority field and
PF queues"), setting up traffic shaping in pf on vlan interfaces has a
side effect where all the packets are sent with the vlan priority field
set to the highest value. This is because hfsc forces the mbuf priority
to the highest value, and that ends up on the wire.
I'd argue this is not what you want. HFSC queuing and packet priority
on the wire are orthoganal, and should be configurable independently.
The diff below allows a packet through HFSC to maintain it's priority,
despite how fast the queueing policy sends it.
This has two consequences. Firstly, it allows mbuf priorities to be
maintained through the system or set in pf, independently of traffic
shaping policy implemented with hfsc.
Secondly, it will allow priority queueing on a vlan interfaces
parent to kick in. With HFSC setting the priority to 7, it made
packets on the physical interface get queued at the highest priority,
but now they get queued at their natural(?) prio.
It could be argued that allowing priq on the parent for HFSC controlled
traffic is good and bad. I think it is more good, as it let's the parent
interface act like the rest of the network that should respect the
vlan prio value.
Adrian has tested this himself and gets the result he expects now.
OK?
Index: hfsc.c
===================================================================
RCS file: /cvs/src/sys/net/hfsc.c,v
retrieving revision 1.47
diff -u -p -r1.47 hfsc.c
--- hfsc.c 13 Apr 2018 14:09:42 -0000 1.47
+++ hfsc.c 22 Oct 2018 07:20:39 -0000
@@ -540,7 +540,6 @@ hfsc_pf_enqueue(void *arg, struct mbuf *
return (m);
ml_enqueue(&cq->q, m);
- m->m_pkthdr.pf.prio = IFQ_MAXPRIO;
return (NULL);
}
