Contradictory/Incorrect/Confusing statements in QMSS UG

Hi John,

              Thanks for clarification and tickets for clearing the confusion. Glad to see quick response/support on this.

Thanks

RC Reddy

Hi John,

              Also can you please explain about the following

====================================================================

RX_FDQ1_QMGR
RX_FDQ1_QNUM

RX_FDQ2_QMGR
RX_FDQ2_QNUM

RX_FDQ3_QMGR
RX_FDQ3_QNUM

Can you please take one example [with 2 Thresholds as well as 3 Thresholds and explain me how to use the above for 1st,2nd,3rd,4th and later Rx buffers ]

Let me request again, kindly explain [with example] w.r.t to 2 Thresholds and 3 Thresholds.

============================================================================

i see a description in UG

"13-12 RX_FDQ1_QMGR Rx free descriptor 1 queue manager index. This field specifies which queue manager should be used for the 2nd

Rx buffer in a host type packet"

============================================================================

questions on the above: - 

say i have sizes Thresholds as Th0,Th1 and Th2

i want to receive data on a linked descriptors [ofcourse, RX Pktdma does in that way if data size is more than a descriptor buffer size]. say for 2nd,3rd,4th and later buffers [== host buffer descriptor], is the buffers [2,3,4 (host buffer descriptors)..etc]picked according to threshold rule.?

If so, why is this setting required [RX_FDQ30_QMGR,RX_FDQ1_QMGR,RX_FDQ2_QMGR]? 

Thanks

RC Reddy

Regarding RX_FDQ1_QMGR/QNUM: these are used to pick up descriptor used for second and subsequent descriptors needed to hold each packet (presuming the first descriptor from RX_FDQ0_SZ#_QMGR/QNUM doesn't have a buffer big enough for the whole packet).  It doesn't have any size based functionality.

Thus if you want to use 2 size thresholds: set RX_SIZE_THRESH_EN to 3; set your two thresholds, and set RX_FDQ0_SZ0_QNUM/QMGR, RX_FDQ0_SZ1_QNUM/QMGR, and RX_FDQ0_SZ2_QNUM/QMGR. 

If you want to use 3 size thresholds, set RX_SIZE_THRESH_EN to 7 and also set the third threshold and RX_FDQ0_SZ3_QNUM/QMGR.

Nobody says that the size of the buffers linked to the descriptors in RX_FDQ0_SZ#_QNUM/QMGR is >= the corresponding RX_SIZE_THRESH(#-1).  Thus if the free descriptor queue has "small" buffers, more than one descriptor will still be needed to finish the packet.  Regardless of the size, the DMA will always get second, third, fourth and subsequent descriptors from RX_FDQ1_QMGR/QNUM, RX_FDQ2_QMGR/QNUM, and RX_FDQ3_QMGR/QNUM.  The first descriptor will use the size of the packet and the size thresholds to pick the first (SOP) descriptor.  The DMA will take as many descriptors as needed to fit the packet (its not limited to 4).

The example that makes use of some of these parameters is the qmss\example\InfrastructureMode example (whose project is qmInfraExampleProject).  This isn't as complete as you are requesting, but it does show how to split a Qmss_QueueHnd into a qnum/qmgr for each of the above arguments.

Again regarding RX_FDQ1[2,3]_QMGR/QNUM.  The "second and subsequent" statement isn't clear.  The HW always takes the first descriptor, based on size, using the RX_FDQ0_SZ# parameters.  The 2,3 and 4th come from RX_FDQ1_QMGR/QNUM, RX_FDQ2_QMGR/QNUM, and RX_FDQ3_QMGR/QNUM respectively.  Any subsequent descriptor needed to finish the packet also come from RX_FDQ3_QMGR/QNUM.  Each of the 3 register sets should be programmed unless you can clearly prove that no packets large enough to require more descriptors can be received.  Note that they can all be programmed to the same queue so you don't have to set up more pools than you want.  Leaving this "blank" means it will go to queue 0 which is probably not the desired behavior.

Hi John,

             I am totally confused. Let me take an example, Please correct me if i am wrong..

a hardware entity in c66 wants to receive different sizes of data, here is what i want to configure.

rxQInfo = Qmss_getQueueNumber (laRxq);

rxFreeQInfo_1 = Qmss_getQueueNumber (Rx1Fdq);
rxFreeQInfo_2 = Qmss_getQueueNumber (Rx2Fdq);
rxFreeQInfo_3 = Qmss_getQueueNumber (Rx3Fdq);

memset (&rxFlowCfg, 0, sizeof(Cppi_RxFlowCfg));

rxFlowCfg.flowIdNum = CPPI_PARAM_NOT_SPECIFIED;
rxFlowCfg.rx_dest_qmgr = rxQInfo.qMgr;
rxFlowCfg.rx_dest_qnum = rxQInfo.qNum;
rxFlowCfg.rx_desc_type = Cppi_DescType_HOST;

rxFlowCfg.rx_ps_location = Cppi_PSLoc_PS_IN_DESC;
rxFlowCfg.rx_psinfo_present = 1; /* Enable PS info */

rxFlowCfg.rx_error_handling = 0; /* Drop the packet, do not retry on starvation by default */
rxFlowCfg.rx_einfo_present = 1; /* EPIB info present */

rxFlowCfg.rx_dest_tag_lo_sel = 0; /* Disable tagging */
rxFlowCfg.rx_dest_tag_hi_sel = 0;
rxFlowCfg.rx_src_tag_lo_sel = 0;
rxFlowCfg.rx_src_tag_hi_sel = 0;

rxFlowCfg.rx_size_thresh0_en = 1; 
rxFlowCfg.rx_size_thresh1_en = 1; 
rxFlowCfg.rx_size_thresh2_en = 0; 
rxFlowCfg.rx_size_thresh0 = 128;
rxFlowCfg.rx_size_thresh1 = 256;
rxFlowCfg.rx_size_thresh2 = 512;

rxFlowCfg.rx_fdq0_sz0_qmgr = rxFreeQInfo_1.qMgr; /* Setup the Receive free queue for the flow */
rxFlowCfg.rx_fdq0_sz0_qnum = rxFreeQInfo_1.qNum;

rxFlowCfg.rx_fdq0_sz1_qmgr = rxFreeQInfo_2.qMgr;
rxFlowCfg.rx_fdq0_sz1_qnum = rxFreeQInfo_2.qNum;

rxFlowCfg.rx_fdq0_sz2_qmgr = rxFreeQInfo_3.qMgr;
rxFlowCfg.rx_fdq0_sz2_qnum = rxFreeQInfo_3.qNum;

rxFlowCfg.rx_fdq0_sz3_qmgr = rxFreeQInfo_3.qMgr;
rxFlowCfg.rx_fdq0_sz3_qnum = rxFreeQInfo_3.qNum;

rxFlowCfg.rx_fdq1_qnum = rxFreeQInfo_1.qNum; /* Use the Rx Queue to pick descriptors */
rxFlowCfg.rx_fdq1_qmgr = rxFreeQInfo_1.qMgr;
rxFlowCfg.rx_fdq2_qnum = rxFreeQInfo_1.qNum; /* Use the Rx Queue to pick descriptors */
rxFlowCfg.rx_fdq2_qmgr = rxFreeQInfo_1.qMgr;
rxFlowCfg.rx_fdq3_qnum = rxFreeQInfo_1.qNum; /* Use the Rx Queue to pick descriptors */
rxFlowCfg.rx_fdq3_qmgr = rxFreeQInfo_1.qMgr;

my understanding: - 
1. if a packet of size <128 bytes is received, it will be received on RXFDQ1. Agreed ? 

2.  if a packet of 128 < size < 256 bytes is received, it will be received on RXFDQ2. Agreed ? 

3.  if a packet of 256 <size < 512 bytes is received, it will be received on RXFDQ3. Agreed ? 

4. lets say if the hardware entity has entity which is more than 512 and now its time for putting the data in linked descriptor format.

say the hardware receives 768 bytes of data,

A) for first 512 bytes of data, RXFDQ3 based desc-buf combination is used.agreed?

B) a second desc-buf combination is pulled from RXFDQ1 [since we have specified ] and the remaining 128 bytes data will be fit inside desc-buf combination pulled from RXFDQ1. agreed ?

5. lets say if hardware receives 1024 bytes,

A) first desc-buf is from RXFDQ3. [512]

B) second desc-buf is from RXFDQ1. [128]

C) third desc-buf is from RXFDQ1. [128]

D) fourth desc-buf is from RXFDQ1 [128].

E) fifth desc-buf is from RXFDQ1 [128].

is the above step 5 and associated sub points are correct, please confirm.

Thanks

RC Reddy

Hi John,

             I am awaiting your reply on the above example/post.

Thanks

RC Reddy

RCReddy said:

my understanding: - 
1. if a packet of size <128 bytes is received, it will be received on RXFDQ1. Agreed ? 

Yes

RCReddy said:

2.  if a packet of 128 < size < 256 bytes is received, it will be received on RXFDQ2. Agreed ? 

Yes

RCReddy said:

3.  if a packet of 256 <size < 512 bytes is received, it will be received on RXFDQ3. Agreed ? 

Yes, but not because its between 256 and 512.  The 512 plays no role since you set rxFlowCfg.rx_size_thresh2_en = 0; 

RCReddy said:

4. lets say if the hardware entity has entity which is more than 512 and now its time for putting the data in linked descriptor format.

say the hardware receives 768 bytes of data,

A) for first 512 bytes of data, RXFDQ3 based desc-buf combination is used.agreed?

B) a second desc-buf combination is pulled from RXFDQ1 [since we have specified ] and the remaining 128 bytes data will be fit inside desc-buf combination pulled from RXFDQ1. agreed ?

Since the packet is 768 bytes, it will draw the first descriptor from rxFlowCfg.rx_fdq0_sz2_qmgr/qnum (not rxFlowCfg.rx_fdq0_sz3_qmgr/qnum  because you disabled the thresh2).  It then looks into the descriptor it draws to see the size of the linked buffer.  This size need not be 512.  The actual size of the buffer was set using Cppi_setData() when you pushed them into the Rx3Fdq. I am assuming that you use Cppi_setData() to assign 512 byte buffers to the descriptors in Rx3Fdq, 256 byte buffers to the descriptors in Rx2Fdq, and 128 byte buffers in Rx1Fdq.  If this is correct, then you will indeed find 512 bytes in the first descriptor which was taken from Rx3Fdq, and teh remaining 128 bytes in the second descriptor that is taken from Rx1Fdq (because rxFlowCfg.rx_fdq1_qnum was set to Rx1Fdq).

RCReddy said:

5. lets say if hardware receives 1024 bytes,

A) first desc-buf is from RXFDQ3. [512]

B) second desc-buf is from RXFDQ1. [128]

C) third desc-buf is from RXFDQ1. [128]

D) fourth desc-buf is from RXFDQ1 [128].

E) fifth desc-buf is from RXFDQ1 [128].

This is correct assuming the buffers linked to the descriptors in RxFdq3 are 512 bytes and RxFdq1 are 128 bytes.

The following are the key punchlines from your example:

1. The sizes in rxFlowCfg.rx_size_thresh# do NOT set the sizes of the buffers in the associated FDQ.  Instead, those sizes were set with Cppi_setData() when you initialized the descriptors in the FDQ.  They need NOT be set to be the same! 
2. The rxFlowCfg.rx_size_thresh2 = 512 has no effect because rxFlowCfg.rx_size_thresh2_en = 0.
3. In your 1024 byte example, each of rxFlowCfg.rx_fdq#_qnum/qmgr were actually used, they just drew from the same queue because they were all set to RxFdq1.

Hi Michael,

Thanks for your update.

I do agree there is incorrect documentation for RX_FDQ0_SZ1_QMGR and RX_FDQ0_SZ1_QNUM fields and there is a proposed one below:

Current:

13-12 RX_FDQ0_SZ1_QMGR RX free descriptor 0 queue manager index – size 1: This field specifies which queue manager should be used for the 1st RX buffer in a packet whose size is less than or equal to the RX_SIZE0 value.

This field is optional.

11-0 RX_FDQ0_SZ1_QNUM RX free descriptor 0 queue index – size 1: This field specifies which free descriptor queue should be used for the 1st RX buffer in a packet whose size is less than or equal to the RX_SIZE0 value. This field is optional

Proposed:

13-12 RX_FDQ0_SZ1_QMGR RX free descriptor 0 queue manager index – size 1: This field specifies which queue manager should be used for the 1st RX buffer in a packet whose size is less than or equal to the rx_size1 value. This field is optional.

11-0 RX_FDQ0_SZ1_QNUM RX free descriptor 0 queue index – size 1: This field specifies which free descriptor queue should be used for the 1st RX buffer in a packet whose size is less than or equal to the rx_size1 value. This field is optional

I don't think, there is incorrect documentation for RX_FDQ0_SZ3_QMGR and RX_FDQ0_SZ3_QNUM fields and the current below seems to be fine but still let me check for  RX_FDQ0_SZ3_QMGR  field which I think needs more clarification on the "the first RX buffer in a packet whose size which is not less than or equal to the rx_size3 value" and to my knowledge, it should be "the first RX buffer in a packet whose size is less than or equal to the rx_size3 value" but again, this may not be true too which needs confirmation from the internal team.

Current:

13-12 RX_FDQ0_SZ3_QMGR RX free descriptor 0 queue manager index – size 3. This field specifies which queue manager should beused for the first RX buffer in a packet whose size was not less than or equal to the rx_size3 value. This field is optional. This queue manager is selected if the packet length does not match any enabled size threshold.

11-0 RX_FDQ0_SZ3_QNUM RX free descriptor 0 queue index – size 3. This field specifies which free descriptor queue should be used for the first RX buffer in a packet whose size is less than or equal to the rx_size3 value. This field is optional. This queue number is selected if the packet length does not match any enabled size threshold.

Thanks & regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question

-------------------------------------------------------------------------------------------------------