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.

C6670 IP reassembly support on PA

Hi,

Is PA supports reassembling of IP packets?

Thanks in Advance.

Regards,

K. Lakshmanan

  • Hi Lakshmanan,

    I suggest you to use the latest CCSv5.2 and the MCSDK, in which NDK is packaged.  If you have any issues – let us know. Here are the links.

     http://processors.wiki.ti.com/index.php/Download_CCS

    http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/latest/index_FDS.html

    In PA module itself there is a unit test under “..\pdk_C6670_1_1_2_6\packages\ti\drv\pa\test\PAUnitTest\tests\test10.c” which provides reference for IP fragmentation and reassembly".

    Thanks.

  • Hi Rajasekaran,

    I have gone through the PA Unit Test code in which Reasssemble of IP packets done at the host side using PA.

    Whether PA itself will do the IP reassemble without host involving nd give reassmebled packet to the host?

    And also the mentioned example code works for the IP packet transmission from the single endpoint and also there is no error case handling like Ip fragments received out of order.

    Regards,

    K. Lakshmanan

  • Hi,
     
    Below will give the clear picture on  my requirement:
     
    One of customer project, we need full fledged IP stack functionalities. ( IPv4/IPv6 fragmentation and reassmebly, IPSEC, ARP, PING, DHCP etc).

    Based on our study and analysis, we find that either PA or NDK will not able to satisfy this requirements mentioned above. Request your comment on this.

    Our understanding on PA

    IP packet fragment and reassembling:

    PA as such not support fragmentation and reassmebly. Understood from PA Unit Test code, with host involvement IP packets will be fragmented and reassembled by PA.
    Our concern is that it takes CPU cycles and also this PA Unit test code doesn't seems like handling Error scenarios like
    -    Timeout option for not receiving fragment packet. (eventhough TI claims timer support, )
    -    Packet reception and reassemble from two endpoints
    Kindly comment on the above.


    Do you have values on CPU utilization for PA-Assisted IP reassembly with host involvement?
    Apart from reassembly,  whether PA will do the fragment of IP packet and form the IP header for the fragmented packets?

    From the PA sample code, we also seen the fragmentation of IP packets with host involvement.
    Please comment whether it can be used for fragmentation purpose?

    ARP, DHCP, PING etc

    We understand that PA doesn't support for IP stack functions like ARP, DHCP and PING. In this case,
    application need to take care these function. Is our understanding is correct?
    However we found that IPSEC support is available in PA.

    Our understanding on NDK:

    NDK provides the functions like IP packets reassemble and fragmentation. And also it provides the IP stack
    functionalities like ARP, PING and DHCP.
    However from the below link, NDK doesn't support for handling (both send and receive) IPSEC packets.Please confirm?
     
    http://e2e.ti.com/support/embedded/tirtos/f/355/p/125607/1084716.aspx#1084716

    Also the CPU cycles it took maximum of 23% (from our profiling with UIA) in case of 40/40Mbps (Network packet receive and Send
    using helloworld Ndk based sample code) with packet size of 1400bytes. With decreasing packet sizes,
    we observed the utilization of CPU cycles is still increasing. Hence this becomes the big bottleneck for enabling the NDK.

    Infact, we enabled L1D cache in the sample code for NDK, there was no improvement in terms of CPU utilization.

    Can anyone suggest to reduce the utilization of CPU cycles incase of NDK?


    Thanks in Advance,


    Regards,
    K. Lakshmanan


  • Dear All,

    Any suggestion on the above queries.

    Regards,

    K. Lakshmanan

  • PA does not support fragmentation and reassmebly. NDK doesn't support IPSec.

    Regards, Eric