Hi, FYI. Went through these old discussions while updating Traffic manager documentation and felt the technical discussion might benefit the group.
Regards, Bala ---------- Forwarded message ---------- From: Barry Spinney <spin...@mellanox.com> Date: 15 April 2016 at 23:41 Subject: RE: Marking API To: Bala Manoharan <bala.manoha...@linaro.org> Do you mind if we invite Bill. That way he can be the tiebreaker if we don’t agree at the end. I really want to close this asap. Regarding suitable time, - 15 minutes after you get back to me (assuming Bill is free). Thanx Barry. *From:* Bala Manoharan [mailto:bala.manoha...@linaro.org] *Sent:* Friday, April 15, 2016 1:17 PM *To:* Barry Spinney *Subject:* Re: Marking API Hi Barry, I do not have an issue with setting the DSCP field but the real question is whether we provide the freedom to set all the 6 bits of DSCP field to application. Currently with your proposal there is a freedom for the application to set all the 6-bits of DSCP filed to any value it wants, I would like to restrict this since for establishing drop precedence as per RFC 2597 for all 4 AF classes can be achieved by altering bits 1 and 2 alone and IMO this value can be changed by the implementation by just getting the drop precedence enabled or disabled boolean set by the application. Class 1 Class 2 Class 3 Class 4 +----------+----------+----------+----------+ Low Drop Prec | 001010 | 010010 | 011010 | 100010 | Medium Drop Prec | 001100 | 010100 | 011100 | 100100 | High Drop Prec | 001110 | 010110 | 011110 | 100110 | +----------+----------+----------+----------+ Any programming logic can be efficiently performed in SW as you have explained yourself but when traffic manager is implemented in HW the options are really limited and we can only set 4 bits in the output packet based on packet colour. If there comes a HW implementation in the future with ability to modify DSCP bit to any value depending upon packet colour then we can add this feature as optional and I will NOT object the same :) P.S: Maybe we can have a quick HO so sort out this issue. Pls suggest your suitable time. Regards, Bala On 15 April 2016 at 20:36, Barry Spinney <spin...@mellanox.com> wrote: Why not add a dscp field bit mask? For example using RFC 2597 code points listed on page 6, which are divided into 4 classes and 3 drop precedence levels, one could set the pkt to MEDIUM DP (say for yellow) by using a bit mask of 0b000110 and a dscp value of 0b000100 and to set the pkt to HIGH DP (say for red) one would use the same bit mask of 0b000110, but a dscp value of 0b000110. The algorithm foe setting JUST the dscp field would be effectively “dscp = (dscp & ~dscp_mask_parameter) | (new_dscp_parameter & ~dscp_mask_parameter)”. If properly coded (i.e. doing precomputations) then this probably takes one extra ld byte instruction over the specific case. Regarding performance ANY change in the TOS field for a SW implementation like linux-generic may be dominated by the cost of updating the IPv4 header checksum. Because of this I have coded up an “incremental” IPv4 header checksum algorithm, which probably still takes more cycles than the TOS masking and oring above. Thanx Barry. *From:* Bala Manoharan [mailto:bala.manoha...@linaro.org] *Sent:* Friday, April 15, 2016 8:03 AM *To:* Barry Spinney *Subject:* Re: Marking API Hi Barry, I agree with the fact that the APIs should not be too oriented with any one platform, but the reason behind my arguments is that it is difficult to manipulate 6-bits of DSCP per packet for each colour, this will be a performance bottleneck if not supported directly in the HW. Most implementations should be capable of supporting HIGH and MEDIUM drop precedence since it only affects 2 bits out of 6 DSCP bits. Hence the requirement from my side is that the marking APIs can support ability to enable Drop Eligibility, ECN and Drop precedence as a boolean per color. I would like to remove the ability to set all the 6-bits of DSCP field since it increases the number of bits needed to be modified per packet per colour. If my explanation is not clear, we can both have a quick HO to sort out the issue. Regards, Bala On 15 April 2016 at 11:23, Barry Spinney <spin...@mellanox.com> wrote: So I have documented and implemented all of the agreed upon marking changes BUT I haven't had the time to research the "subset of the diffserv 6 bits used for Drop Eligible". Instead can you send me EXACTLY how your HW sets a subset of these 8 TOS bits? Or help me boil down the RFC into a simple algorithm like "if (this is so) then use this bit mask to clear some of the 6/8 bits and then or in this bit value else use some other technique to set the 6/8 bits like so". I STILL would like to be able to have the final algorithm be able to set the 6 bit dscp value arbitrarily - based on color" - even if your HW does NOT allow this. I.e. I don't want to have the marking API ONLY match Cavium HW and nothing else. Thanx Barry. (p.s. All my tests seem to now work fine and so hopefully tomorrow I will be starting to submit the "final" patches (well at least final for this week)).
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
