On Mon, Oct 22, 2018 at 05:30:54PM +1000, David Gwynne wrote: > 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?
I agree that changing the prio in hfsc enqueue is not right and not needed. OK claudio@ > 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); > } > > -- :wq Claudio
