• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 552 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PA configuration cmd response queue in multicore example (with modifications)

Aamir Husain
Expert 2715 points

Hi Ti Folks,

I had a question on PA configuration Cmd response Queue Handler.

I have a multicore implementation of the multicoreExample running on two cores with 512 descriptors set up with the first 128 reserved for TX descriptors and the other 384 broken across 2 cores with 192 each for Rx descriptors. I have further broken down the 192 descriptors into 64 descriptors for use when Ethernet packets are sent to the DSP on UDP ports other than a specified one. The other 128 descriptors are for the Ethernet traffic on the specified port. This is for us to internally distinguish between Ethernet and Command traffic over Ethernet. Now when I set up different aspects, rules etc in the PA i.e. in the Setup_PASS(), in any given function called, I pop a descriptor of the TX free Queue, get the cmdReplyQInfo from the Qmss_getQueueNumber (gPaCfgCmdRespQHnd) and then call the PA LLD api to prepare the command and then push it onto the TxQHnd and then await a response on the CmdRespQHnd. My question is why is the response received using the first set of Rx descriptors i.e on Command descriptors. How is this configured as all that happens as far as setup is concerned is in the Init_PASS() function call we setup the gPACfgCmdRespQHnd= Qmss_queueOpen(General purpuse queue)? Is it that the default for the cmd response is to use the  first flow configured. So all responses come back in this buffer even for the othere queues. I am just trying to understand it in case I would like to have these responses make use of another set of descriptors.

Thanks, Aamir

 

  • 0
    Expert 2715 points

    In the above posting, I meant to say that  "So all the responses come back in this buffer even for the other core's" in the second last line. Sorry about the typo.

    Aamir

  • 0
    TI__Intellectual 2810 points

    Hi, Aamir:

    The receive descriptor is based on the CPPI flow ID you specified for all the traffic from PASS including command response packet and ingress packets. If you want to use multiple descriptor pools, you need to configure multiple CPPI flows and specify the flow Id with Pa_addxxx APIs. Please note that example just example. There will be multiple way to achieve your design goal.

    /**
     *   @ingroup palld_api_structures
     *   @brief  paCmdReply_t is used to specify command result (from PASS) routing information
     *
     *   @details Commands sent to packet accelerator sub-system will generate replies. These replies
     *            can be either discarded by the sub-system or routed to a queue. Command replies that
     *            must be forwarded back to this module are detailed for each command. The module user
     *            typically either selects a unique destination queue for command replies, or else supplies
     *            a unique value for replyId. This value is placed into software info word 0 in the
     *            packet descriptor for the returned command. The data in the returned packet is not
     *            typically examined by the module user, but passed directly back to this module through
     *            API function @ref Pa_forwardResult to examine the results of the command.
     */
    typedef struct  {

      int       dest;        /**<  Packet destination, must be pa_DEST_HOST or pa_DEST_DISCARD, see @ref pktDest */
      uint32_t  replyId;     /**<  Value placed in swinfo0 in reply packet */
      uint16_t  queue;       /**<  Destination queue for destination pa_DEST_HOST */
      uint8_t   flowId;      /**<  Flow ID used on command reply from PASS */
     
    } paCmdReply_t;

    /**
     *  @ingroup palld_api_structures
     *  @brief  Packet routing configuration
     *
     *  @details paRouteInfo_t is used to specify the physical routing of packets out of the packet accelerator
     *           sub-system. Not all fields are required for all destinations.
     *  @li      pa_DEST_DISCARD: none
     *  @li      pa_DEST_CONTINUE_PARSE_LUT1:
     *  @li      pa_DEST_CONTINUE_PARSE_LUT2: customType, customIndex
     *  @li      pa_DEST_HOST: flowId, queue, mRoutehandle, swInfo0, cmd
     *  @li      pa_DEST_SASS: flowId, queue, swInfo0, swInfo1, cmd
     *  @li      pa_DEST_ETH: emacCtrl
     *  @li      pa_DEST_SRIO: flowId, queue, swInfo0, swInfo2, pktType
     */
    typedef struct  {

      int      dest;                  /**<  Packet destination as defined at @ref pktDest */
      uint8_t  flowId;                /**<  For host, SA or SRIO destinations, specifies CPPI flow which defines free queues are used for receiving packets */
      uint16_t queue;                 /**<  For host, SA or SRIO destinations, specifies the destination queue */
      int      mRouteIndex;           /**<  For host, Multi-queue routing index (0 to (@ref pa_MAX_MULTI_ROUTE_SETS - 1))
                                            or @ref pa_NO_MULTI_ROUTE if multi routing not used */
      uint32_t swInfo0;               /**<  Placed in SwInfo0 for packets to host or SA; Placed in the PS Info for packets to SRIO */
      uint32_t swInfo1;               /**<  Placed in SwInfo1 for packets to the SA; Placed in the PS Info for packets to SRIO */
      int      customType;            /**<  For CONTINUE_PARSE_LUT1/LUT2 only, specifies the custom type as defined at @ref customType */
      uint8_t  customIndex;           /**<  For CONTINUE_PARSE_LUT1/LUT2 only, specifies the custom classification entry index */                               
      uint8_t  pktType_emacCtrl;      /**<  For destination SRIO, specify the 5-bit packet type toward SRIO
                                            For destination HOST, EMAC, specify the EMAC control @ref emcOutputCtrlBits to the network */
      paCmdInfo_t *pCmd;              /**<  Pointer to the Command info to be executed prior to the packet forwarding.
                                            NULL: no commads
                                            @note only the following commands are supported within paRouteInfo_t
                                                  - pa_CMD_PATCH_DATA (up to two bytes only) (LUT2 only)
                                                  - pa_CMD_CMDSET
                                                  - pa_CMD_USR_STATS
                                                  - pa_CMD_CMDSET_AND_USR_STATS
                                       */                                                                                   

    } paRouteInfo_t;

     Best regards,

    Eric

     

     

     

     

  • 0 in reply to Eric Ruei
    Expert 2715 points

    Eric,

    Thanks for your reply. That clarifies it as the paCmdReply_t I have set uses 0 as the flow ID so it ends up using that for the response. I should be able to figure out how to program this. I have another post that I am just about to post and would appreciate an answer on. It has to do with Tx queues and sending packets out.

    Thanks, Aamir