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.

NDK and Packet Accelerator[PA] [c6670/c6678]

Hi Ti Folks,

                Sorry for more questions on NDK and Packet Accelerator. Lets say, I have a system already working with NDK driver [the project consists of NDK interface code based on Client example project/code from Ti installation folders ] and it is receiving ethernet packets from external world [no worries, i am happy about it]. I am adding PA related Classification code to the existing project [which contains NDK].

1. Assuming a case wherein ethernet packets from external world reach the CPSW, will they be forwarded as they are NDK packets or will they be discarded/dropped as they do not match classification criterion/rules [Mac match, IP match and port match]. Kindly explain what happens in this case. 

2. If they are dropped, how to make a work around for the same [i assume broadcast IP/sMacs is one such option, any other option, please let me know].

3. Does The Packet Classification code [PA LLD] conflict with NDK Interface code or they are two seperate different parallel entities [In other words, one is mutually exclusive of other]?

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

I see two Ti e2e posts saying that NDK is no way related to PA.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/147286.aspx

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/194486.aspx

and at the same time, i see NDK does use PA in the MCSDK diagram [MCSDK UserGuide and MCSDK wiki page]. Kindly confirm which is correct

http://processors.wiki.ti.com/index.php/File:Ndkarch.png

Also Hellworld NDK project does use the res_mgr_init_pass [PA initialization/configuration related API], so i assume that NDK does use PA?? please confirm.

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

Thanks

RC Reddy

  • Hi All,

                      I did gave a look into deeper code of NDK a little while back,

    Here is my understanding based on code.
    NC_NetStart is must in case of NDK
    NC_NetStart()  -->     /* Initialize the Network Interface Management Unit */ NIMUInit (&stkEvent); -->    while (NIMUDeviceTable[index].init != NULL) 
    The NIMUDeviceTable is as follows
    NIMU_DEVICE_TABLE_ENTRY NIMUDeviceTable[] =
    {
    /**
      * @brief  EmacInit for the platform
      */
        EmacInit,
        NULL
    };
      static int EmacInit (STKEVENT_Handle hEvent)
    {
        EMACInit_Core(hEvent);
        return 0;
    }
    static int EMACInit_Core (STKEVENT_Handle hEvent)
    {
        /* Populate the Driver Interface Functions. */
        ptr_device->start       = EmacStart;
        ptr_device->stop        = EmacStop;
        ptr_device->poll        = EmacPoll;
        ptr_device->send        = EmacSend;
        ptr_device->pkt_service = EmacPktService;
        ptr_device->ioctl       = Emacioctl;
        ptr_device->add_header  = NIMUAddEthernetHeader;
        /* Init PA LLD */
        if (Init_PASS () != 0)
        {
         platform_write ("PASS init failed \n");
            return -1;
        }
        else
        {
         platform_write ("PASS successfully initialized \n");
        }
        /* Initialize the CPSW switch */
        if (Init_Cpsw ((uint32_t) ptr_device->mtu,  ptr_pvt_data->pdi.bMacAddr) != 0)
        {
         platform_write ("Ethernet subsystem init failed \n");
            return -1;
        }
        else
        {
         platform_write ("Ethernet subsystem successfully initialized \n");
        }
    }
    static int EmacStart
    (
        NETIF_DEVICE*     ptr_net_device
    )
    {
        EMAC_DATA*      ptr_pvt_data;
        paMacAddr_t     broadcast_mac_addr  = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
        paEthInfo_t     ethInfo             = { { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 },     /* Src mac = dont care */
                                                { 0x10, 0x11, 0x12, 0x13, 0x14, 0x15 },     /* Default Dest mac */
                                                  0,                                        /* vlan = dont care */
                                                  0,                                        /* ignore ether type */
                                                  0                                         /* MPLS tag = don't care */
                                              };
        paRouteInfo_t   routeInfo           = { pa_DEST_HOST,           /* Route a match to the host */
                                                0,                      /* Flow ID 0 */
                                                0,                      /* Destination queue */
                                                -1,                     /* Multi route disabled */
                                                0xaaaaaaaa,             /* SwInfo 0 */
                                                0,                      /* SwInfo 1 is dont care */
                                                0,                      /* customType = pa_CUSTOM_TYPE_NONE */         \
                                                0,                      /* customIndex: not used */        \
                                                0,                      /* pkyType: for SRIO only */       \
                                                NULL                    /* No commands */
                                              };
        /* Get the pointer to the private data */
        ptr_pvt_data = (EMAC_DATA *)ptr_net_device->pvt_data;
        /* Setup Tx */
        if (Setup_Tx () != 0)
        {
            platform_write ("Tx setup failed \n");
            return -1;
        }
        /* Setup Rx */
        if (Setup_Rx (ptr_net_device) != 0)
        {
         platform_write ("Rx setup failed \n");
            return -1;
        }
        memcpy (&ethInfo.dst[0],  ptr_pvt_data->pdi.bMacAddr,  sizeof(paMacAddr_t));
        /* Set up the MAC Address LUT*/
        if (Add_MACAddress (&ethInfo, &routeInfo) != 0)
        {
         platform_write ("Add_MACAddress failed \n");
            return -1;
        }
        memcpy (&ethInfo.dst[0],  broadcast_mac_addr,  sizeof(paMacAddr_t));
        /* Set up the MAC Address LUT for Broadcast */
        if (Add_MACAddress (&ethInfo, &routeInfo) != 0)
        {
         platform_write ("Add_MACAddress failed \n");
            return -1;
        }
        /* Verify the Tx and Rx Initializations */
        if (Verify_Init () != 0)
        {
         platform_write ("Warning:Queue handler Verification failed \n");
        }
    ========================================================
    so all in all, NDK uses PA [based on above code trace], wanted further information from Ti folks about
    1. working of both [NDK and PA] when both are enabled/currently working.?
    2. about my previous/earlier ti e2e post  [in this same thread].
    Thanks
    RC Reddy
  • RC Reddy,

    Have you succeeded with connecting the NDK & the PA?

    Thanks,

    HR 

  • Hi HRi,

               As i put in my above post, NDK uses PA [In other words, NDK is already connected to PA]. For my application, i don't use NDK anymore, i am using PA LLD.

    Thanks

    RC Reddy


  • Hi RC Reddy,

    NDK is an independent stack and does not do any hardware setup directly. NDK calls into the respective device's NIMU. This NIMU layer calls underlying hardware driver/CSL.

    http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide#Network_Interface_Management_Unit_.28NIMU.29_Driver

    In case of C6670/8devices, the NIMU code does not use PA. It bypasses PA and sends packet directly to the QMSS Q#648.

    Hope you are having no issues using the PA LLD directly. There are some examples at "..\pdk_C667x_x_y_z\packages\ti\drv\pa\example"

  • Hi Varada,

                    Thanks for reply. NDK calls NIMU, agreed. NIMU calls PA configuration/setup [please see the code flow i put]. doesn't that mean NDK is indirectly calling PA configuration/setup[i meant in that sense]. 

    This is egress path ""In case of C6670/8devices, the NIMU code does not use PA. It bypasses PA and sends packet directly to the QMSS Q#648.

    what about ingress path?? 

    Thanks

    RC Reddy

  • Okay - I understand your statement. Even on ingress path, the PA is by dafault bypassed.

  • Varada,

    When will there be a NIMU + PA version?

    Thanks,

    HR

  • I don't agree. In Add_Mac_address function, as I remember, there is configuring of PDSP1 to filter packets by added MAC-address.

  • Hi Varada,

                     In Ingress path, who/which entity is dropping the packets [which does not match the IP address, Port, Mac Address]. also tell me who is doing the matching [mac address matching, ip address matching, port matching, protocol matching] task.

    Also please detail clearly the egress path and ingress path [peripherals/physical entities which is being touched/traversed along packet path].

    Thanks

    RC Reddy 

  • Hi, All:

    I am sorry for the interruption. Just want to clarify the matters for RC. TI provides both NDK and PA LLD. The application can either use NDK or PA LLD with a network stack provided by the customer himself. If you choose to use NDK, you application should interface with NDK only, i.e. invoking NDK APIs for all data traffic. If you choose to use PA LLD, you need to write your own network stack to interface with PA LLD and other low layer software stacks such as CPPI and QMSS LLDs.

    The NDK itself is devbice-independent. It use the device-specific NIMU to interface with low-level device driver. In the current implementation, the TCI6678 NIMU only uses PASS to perform device MAC address filtering so that only broadcast, multicast and device-specific MAC packet will be delivered to NDK. In the egress directiomn, the tx packets are pushed to the CPSW queue (648) directly. It is up to the platform team to determine how much functionality of PASS that NIMU will take advantage of in the future.

    Best regards,

    Eric

     

     

     

  • Hi Eric,

               Thanks for your reply. ok agreed, PA sub system [called as part of NIMU] does the MAC filtering for ingress packets, who is doing IP/protocol/port matching/filtering.

    Thanks

    RC Reddy

  • Hi, RC:

    The  NDK does all  others. It does not use PASS fully.

    Best regards,

    Eric

     

     

     

     

     

  • Hi, Eric:

    I do not see the logical reason why the IP stack (NDK) should not to be used simultaneously with the use of performance of PA. I thing that the NDK could be used for small bit streams (e.g. control and diagnostics) and the PA could be used for big bit streams (direct application processing).

    Formerly, I used NDK on c6678 for application with incoming 100Mbps and I think that it is maximum of stack capability. Now, I am using only the PA LLD but I would like to add standard IP stack.

    Is there possible to add a second MAC address (eventually IP address and port)  into NIMU, which could serve for the direct transmission of packets to the DDR memory without the load of the NDK? The application's packets could be parsed through the application thread (e.g. in another core).


    Best regars,

    David

  • Hi, David:

    Yes, you can use PA LLD alongside NDK/NIMU. There are fast-path traffics which take the full classification capabilities of PASS to classify and deliver packets to user-specified queues and slow-path traffic where the non-fast-path traffic is delivered to the NDK queue to be processed by NDK.

    You will  need to update the NIMU addMAC operation by setting the routeInfo for pa_DEST_CONTINUE_PARSE_LUT1 and the nextFail Route to pa_DEST_HOST. Then you can configure LUT1/LUT2 entries for the fast-path traffics.

    Best regards,

    Eric

  • Hi, Eric.
    Now, I am using EVMK2H b'd.

    And I'd like to use both Ethernet port.
    NDK running at ETH0 with DSP core0, PA running at ETH1 with DSP core1(not core0).
    From your guiding, I can only use "either" NDK or PA LLD.
    However, what if PA LLD is at differnent DSP core? is it possible? or not?

    I really need help~.

  • Hi, SungBum:

    Yes, you shall be able to NDK -based operation on one DSP core and PALLD-based fast path at another core.
    Please refer to my previous reply to David. If there is only one MAC address, then you need to modify NDK NIMU code as I suggested. If there is different MAC address for different ETH port or DSP, you do not need to modify NDK.

    Please note that the PASS is shared by all DSP and ARM cores so that you can only initialize the PASS once and download the firmware images once.

    Best regards,

    Eric
  • Hi Eric.
    Thank you very much for your reply.
    I could "also" use NDK -based operation on one DSP core(maybe core0) and PA LLD-based fast path at "SAME" core.
    (This is what RCRedd tried to do, I think).
    I prefer run the PA LLD at the same core which NDK runs.
    To sum up, I try to runs NDK at DSP core0(only using for eth0) and PA LLD runs DSP_core0(only using for eht1)
    I ask for clarification. :)
  • Hi, SungBum:

    Yes, you can use both NDK and PA LLD at the same DSP core. Please note that NDK/NIMU uses PA LLD as well.

    PASS owns common resources such as the Type1 Lookup table (LUT1) for MAC/IP entries, the Type2  Lookup table (LUT2) for TCP/UDP entries and their control firmware images to be shared by the entire SoC system including DSP and ARM cores. The PA LLD consists of a set of APIs to initialize the PASS and format the configuration command packets. It is up to the upper layer application to manage the shared PASS resources.

    For your proposed operation, the upper layer application should initialize PASS, download all the firmware images and then invoke NDK/NIMU to add a couple of LUT1 entries at PDSP0 to classify and route ETH0 traffic to NDK and then add the necessary LUT1/LUT2 entries to classify and route the desired ETH1 traffics to your fast paths.

    Please note that you may need to modify the EmacStart() function at packages\ti\transport\ndk\nimu\src\v3\nium_eth.c to include inport as part of matching criteria if there is only one destination MAC for both ports.

    Best regards,

    Eric