Re: dont let hfsc force the packet priority
OK kn
Re: dont let hfsc force the packet priority
> On 22 Oct 2018, at 6:27 pm, Mike Belopuhov wrote: > > > David Gwynne writes: > >> 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 this is odd and you have my OK for the patch. > > However, since HFSC uses its own FIFO queues internally > (that replaces the default priority queueing), this change > won't make an HFSC enabled system do any priority queueing. Yes, but some interfaces have parents which may still have priq enabled. dlg > >> 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 - 1.47 >> +++ hfsc.c 22 Oct 2018 07:20:39 - >> @@ -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); >> }
Re: dont let hfsc force the packet priority
David Gwynne writes: > 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 this is odd and you have my OK for the patch. However, since HFSC uses its own FIFO queues internally (that replaces the default priority queueing), this change won't make an HFSC enabled system do any priority queueing. > Index: hfsc.c > === > RCS file: /cvs/src/sys/net/hfsc.c,v > retrieving revision 1.47 > diff -u -p -r1.47 hfsc.c > --- hfsc.c13 Apr 2018 14:09:42 - 1.47 > +++ hfsc.c22 Oct 2018 07:20:39 - > @@ -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); > } >
Re: dont let hfsc force the packet priority
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.c13 Apr 2018 14:09:42 - 1.47 > +++ hfsc.c22 Oct 2018 07:20:39 - > @@ -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
dont let hfsc force the packet priority
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 - 1.47 +++ hfsc.c 22 Oct 2018 07:20:39 - @@ -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); }
