This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Bug in IP fragments Re-Assembly Example Code (ti\drv\pa\test\PAUnitTest\tests\test10.c) ??

Hi Ti Folks,

                   I have series of following questions on the Test10 of the PAUnitTest [IPV4 Fragmentation and Re-assembly]

1. what is the bug which is talked in this test10.c comments ??

#ifndef SIMULATOR_SUPPORT
/* There is a pending simulator timing prroblem. To be enabled after the simulator bug is fixed */
if ((j == (fragCnt - 1)) && (i == (mid -1)))
{

2. In the OuterIP fragmentation re-assembly code, is this always expected to ONLY work with 2 Streams of data [in other words, 2 traffic flows ] ?? ofcourse in example, the max traffic flows configured is two, so my question is, is this example can support only 2 or can go less also...[i mean single traffic flow case]?

/* Process OutIp fragments */
if (t10RxFrags(tencap, tencap->tf->QGen[Q_IP_REASSM1], tencap->tf->QPaTx[1], &expCount))
{
      return (-1);
}

In other words, Is this example code DESIGNED ONLY FOR TWO Traffic flows at any given time. At every Send and Receive for 10 times

for (k = 0; k < T10_NUM_PACKET_GROUPS; k+=2)

{

  for (i = 0; i < 2; i++) // Here two different streams of UDP packets are generated/Sent/Transmitted [Note: -  each stream of packets has a UNIQUE IDENTIFICATION Field]
  {
     t10SendDataPkts (&t10Encap, paT10NumTestPkts, k + i, i == 0);
   }

   if (t10ReceiveDataPkts (&t10Encap, paT10NumTestPkts * i))
   {
     System_printf ("%s (%s:%d): Receive packets fail\n", tfName, __FILE__, __LINE__);
     t10Cleanup (&t10Encap, PA_TEST_FAILED);
   }
}

3. Elaborating more on point 2, if i make the FOR LOOP to iterate only ONCE, though the pa_control is for two traffic flows. only one stream of udp packets are sent [In other words, all UDP packets belong to same IDENTIFICATION FIELD]

 for (i = 0; i < 1; i++) //

i see the code failing to reassemble the packet. I assume this is a bug in the example code.? please comment...

4. the assembly code fails for just two packet fragmented packets, both having same IDENTIFICATION FIELD.

Please confirm if this is fixed or any new example is provided in newer versions of PDK example projects [i am using PDK 21 Package]

5. if the FOR loop, is made for 1 iteration [Here i will talk about only first 2 Receives/Iterations of 10 Iterations]. In second iteration, there are ONLY two packets to be reassembled and the code fails in doing so.

Fragment Count 4 ===== first receive
protocol 17,id 0,saddr 9eda6d0b,daddr c8c9ca64
protocol 17,id 0,saddr 9eda6d0b,daddr c8c9ca64
protocol 17,id 0,saddr 9eda6d0b,daddr c8c9ca64
protocol 17,id 0,saddr 9eda6d0b,daddr c8c9ca64
Fragment Count 2 ===== second receive
protocol 17,id 0,saddr 9eda6d21,daddr c8c9ca66
protocol 17,id 0,saddr 9eda6d21,daddr c8c9ca66

Please check the second receive, at this below piece of code, that IF LOOP has to pass this condition and this doesn't pass and also the there is NO REASSEMBLED packet being pushed onto the qmss queue 641 [as the condition is never met (if(pReassemblyInfo)) ]

/* Check if the reassembly is complete? */
if (pIPReassemblyBlock->orignalLen == pIPReassemblyBlock->detectedLen)

if(pReassemblyInfo)
{
/* Reassembly packet is ready */
reassembledHd = pReassemblyInfo->pHostDesc;
ipHdr = (uint8_t *)(reassembledHd->buffPtr + ipOffset);

Also please let me know if any further issues/bugs were reported in this example, so that i can take care of those in my implementation.

Thanks

RC Reddy

  • Hi, Reddy:

    Please keep in mind that the unit test is designed to verify the IP fragmentation and reassembly functionalities of PASS in a simplest way without external devices. For example, we use a very simple mechanism to generate out of order packets and make sure there are more than one active traffic flow. It is not intended for actual application code to handle IP fragmentation and reassembly. You should just learn the basic principles of IP fragmentation and reassembly-assisted operation in test10.c. I shall try to answer your specific questions below:

    Hi Ti Folks,

                       I have series of following questions on the Test10 of the PAUnitTest [IPV4 Fragmentation and Re-assembly]

    1. what is the bug which is talked in this test10.c comments ??
    [Eric] This operation does not work in the functional simulator. It amy be due to lack of buffers or other issues. We did not debug this problem since both C6670 and C6678 (real silicon) EVMs are available and this operation works.

    #ifndef SIMULATOR_SUPPORT
    /* There is a pending simulator timing prroblem. To be enabled after the simulator bug is fixed */
    if ((j == (fragCnt - 1)) && (i == (mid -1)))
    {

    2. In the OuterIP fragmentation re-assembly code, is this always expected to ONLY work with 2 Streams of data [in other words, 2 traffic flows ] ?? ofcourse in example, the max traffic flows configured is two, so my question is, is this example can support only 2 or can go less also...[i mean single traffic flow case]?

    [Eric] Please refer to pa.h or doxygen for general limitation. Please note it is just an internal test and sample code. You should use it as a reference only.

    /**
     *  @ingroup palld_api_structures
     *  @brief  IP Reassembly Configuration Information.
     *
     *  @details  paIpReassmConfig_t is used to configure the PA-assisted IP reassembly operation. Two separate structures are used
     *            for the outer IP and inner IP respectively. The IP reassembly assistance feature is disabled until
     *            this information is provided. See section @ref appendix3 for deatiled description.
     *  @note The maximum number of traffic flows is limited due to processing time and internal memory restriction.
     */
    typedef struct {

      uint8_t numTrafficFlow; /**< Maximum number of IP reassembly traffic flows supported, default = 0, maximum = 32 */
      uint8_t destFlowId;     /**< CPPI flow which instructs how the link-buffer queues are used for forwarding packets */
      uint16_t destQueue;     /**< Destination host queue where PASS will deliver the packets which require IP reassembly assistance */

    } paIpReassmConfig_t;

    /**
     *  @ingroup palld_api_constants
     *  @brief   Define the maximum number of IP reassembly traffic flows
     *
     */
    #define pa_MAX_IP_REASM_TRAFFIC_FLOWS   32

    /* Process OutIp fragments */
    if (t10RxFrags(tencap, tencap->tf->QGen[Q_IP_REASSM1], tencap->tf->QPaTx[1], &expCount))
    {
          return (-1);
    }

     

    In other words, Is this example code DESIGNED ONLY FOR TWO Traffic flows at any given time. At every Send and Receive for 10 times

    for (k = 0; k < T10_NUM_PACKET_GROUPS; k+=2)

    {

      for (i = 0; i < 2; i++) // Here two different streams of UDP packets are generated/Sent/Transmitted [Note: -  each stream of packets has a UNIQUE IDENTIFICATION Field]
      {
         t10SendDataPkts (&t10Encap, paT10NumTestPkts, k + i, i == 0);
       }

       if (t10ReceiveDataPkts (&t10Encap, paT10NumTestPkts * i))
       {
         System_printf ("%s (%s:%d): Receive packets fail\n", tfName, __FILE__, __LINE__);
         t10Cleanup (&t10Encap, PA_TEST_FAILED);
       }
    }

    [Eric] It is just a simple way to generate multiple streams. This mechanism will not be used at real application.

    3. Elaborating more on point 2, if i make the FOR LOOP to iterate only ONCE, though the pa_control is for two traffic flows. only one stream of udp packets are sent [In other words, all UDP packets belong to same IDENTIFICATION FIELD]

     for (i = 0; i < 1; i++) //

    i see the code failing to reassemble the packet. I assume this is a bug in the example code.? please comment...

    [Eric] The unit test code works as a whole. If you make some change in one area, you may need to change some other corresponding code area. I am not sure what you intend to test.  If multiple stream works, single traffic stream will work.

    4. the assembly code fails for just two packet fragmented packets, both having same IDENTIFICATION FIELD.

    Please confirm if this is fixed or any new example is provided in newer versions of PDK example projects [i am using PDK 21 Package]

    [Eric] What do you mean by two packets with the same ID field.? All packets with the same SMAC, DMAC and protocol should contain different IDs.

     

    5. if the FOR loop, is made for 1 iteration [Here i will talk about only first 2 Receives/Iterations of 10 Iterations]. In second iteration, there are ONLY two packets to be reassembled and the code fails in doing so.

    Fragment Count 4 ===== first receive
    protocol 17,id 0,saddr 9eda6d0b,daddr c8c9ca64
    protocol 17,id 0,saddr 9eda6d0b,daddr c8c9ca64
    protocol 17,id 0,saddr 9eda6d0b,daddr c8c9ca64
    protocol 17,id 0,saddr 9eda6d0b,daddr c8c9ca64
    Fragment Count 2 ===== second receive
    protocol 17,id 0,saddr 9eda6d21,daddr c8c9ca66
    protocol 17,id 0,saddr 9eda6d21,daddr c8c9ca66

    Please check the second receive, at this below piece of code, that IF LOOP has to pass this condition and this doesn't pass and also the there is NO REASSEMBLED packet being pushed onto the qmss queue 641 [as the condition is never met (if(pReassemblyInfo)) ]

    /* Check if the reassembly is complete? */
    if (pIPReassemblyBlock->orignalLen == pIPReassemblyBlock->detectedLen)

    if(pReassemblyInfo)
    {
    /* Reassembly packet is ready */
    reassembledHd = pReassemblyInfo->pHostDesc;
    ipHdr = (uint8_t *)(reassembledHd->buffPtr + ipOffset);

    Also please let me know if any further issues/bugs were reported in this example, so that i can take care of those in my implementation.

    [Eric] As I mentioned earlier, the unit test works as a whole. It was not intended to be altered by the user. If you have a specific test scenario, we can discuss.

     

    Thanks

  • Hi Eric,

                Thanks for reply. Let me put what i am trying to achieve.

    1. In the example code, for every iteration, there are two streams of packets being generated.

    when i meant two streams. each stream is a fragmented packets

    for example BIG packet X is fragmented into {x1,x2,x3,x4} ==> stream 1 [All these Packets will have unique ID for them to be reassembled]

    for example BIG packet Y is fragmented into {y1,y2} ==> stream  [All these Packets will have unique ID for them to be reassembled]

    2. I went ahead and modified the code, the FOR loop to generate only one stream [one streaming meaning a set of packets {y1,y2} which are having same unique ID ]

    The receive part of the code is NOT REASSEMBLING THE PACKET. ["If multiple stream works, single traffic stream will work", Kindly run once and check..mm.it didn't work for me]

    3. by this statement, "If you make some change in one area, you may need to change some other corresponding code area"...Then the below pasted code has to be commented for it to work with single STREAM of data.

    if ((j == (fragCnt - 1)) && (i == (mid -1)))
    {
    uint32_t timeoutCnt;
    /*
    * Test IP Reassembly timeout:
    * This fragment (packet) should be the last one within its group
    * If it is an IP fragments, the paEx_reassemLibTimerTick() will flush out the remaining fragments
    * If it is the case, update the corresponding statistics and *pExpCnt
    */
    paIPReassemblyStats_t stats;

    paEx_reassemLibQueryStats(&stats, FALSE);
    timeoutCnt = stats.reassemblyTimeout;

    /* Verify the Reassembly timeout operation */
    paEx_reassemLibTimerTick(5001);

    /* adjust the expected statistics */
    paEx_reassemLibQueryStats(&stats, FALSE);
    timeoutCnt = stats.reassemblyTimeout - timeoutCnt;

    if (timeoutCnt)
    {
    t10IpRreassemTimeoutUpdatesStats(&paTestL4ExpectedStats, timeoutCnt);
    *pExpCnt -= timeoutCnt;
    }

    if (paEx_reassemLibProc(hd[j], outQ))
    {
    System_printf ("%s (%s:%d): sample_procPkts(%d) return error!\n", tfName, j, __FILE__, __LINE__);
    testCommonRecycleLBDesc (tencap->tf, hd[j]);
    return (-1);
    }

    if (timeoutCnt)
    {
    paEx_reassemLibTimerTick(5001); /* kick out the last fragments */
    paTestL4ExpectedStats.classify1.nPackets++; /* There is an extra null packet entering PDSP1/PDSP2 */
    }

    }

    i may be wrong in analyzing the code..so please review from your end also.

    4. "As I mentioned earlier, the unit test works as a whole. It was not intended to be altered by the user. If you have a specific test scenario, we can discuss."

    mmm.ok..i agree the unit test works as a whole. I altered it to see whether it works for single stream of data, it didn't. As u told, i need to change corresponding other code to work with SINGLE stream.

    my test scenario is to pick the MAX supported by PA, 

    1. In my application, the max size of Packet is 65535 bytes [0xFFFF], it can arrive in packets of 1500 bytes, so the Max Fragmented packets possible is 45 [45*1500 = 67500 bytes]. I have qmss set for handling this

    2. and the traffic flows i should be able to support is MAX 32 [pa_MAX_IP_REASM_TRAFFIC_FLOWS  ], so i will increase pConfig->numReassemblyContexts to max possible 32 or more. [ofcourse < 100 to respect MAX LIMIT Condition]

    I commented out the timeout part of the code [as pointed in step 3], i checked for 2 fragmented packet reassembly and 3 fragmented packet reassembly, it works. Let me know if this is correct. I am still investigating..more such scenario..


    Thanks

    RC Reddy

  • Hi Eric

              i didn't get the understand this statement.

    "What do you mean by two packets with the same ID field.? All packets with the same SMAC, DMAC and protocol should contain different IDs."

     what i meant is

    a stream of packets which are fragmented from a big packet carry same Identification field number. 

    BIG packet X broken into 7 pieces

    {x1,x2,x3,x4,x5,x6,x7}..all the 7 packes will have sme Identification field say[1234 = 0x04d2]


    Thanks

    RC Reddy

  • Hi, Reddy:

    I know your intention. But I do not know why you want to midify the unit test code to do that. It is pretty easy to generat a single stream traffic, receive all fragments, send it to the reasse,bly module, and then send the reassembled packet back to PASS. You do not need to use any of the complexity to alter the traffic as in the unit test. We have done massive fragmentation and reassembly tests at the production code. But, I can not comment on your result until I see all the changes you made.

    Best regards,

    Eric

     

     

  • It is correct.

    Eric