TI专家，请教一个6678上关于RX flow的问题

   For loopback PKTDMA modes (i.e. infrastructure cases), the Rx flow is specified in the
   Tx descriptor, in the SOURCE_TAG_LO field. The PKTDMA will pass this value to the
   streaming I/F as flow index.
   In non-loopback cases, the Rx flow is specified in the packet
   info structure of the Streaming I/F.
   In the event no Rx flow is specified, the Rx DMA will use Rx flow N for Rx channel N.
QMSS里边的这个描述我也看到了，而且另外有一个帖子提到过这个问题：
http://www.deyisupport.com/question_answer/dsp_arm/c6000_multicore/f/53/t/60817.aspx
”对于QMSS 内部的infrastructure PKTDMA是像你说的那样由Tx descriptor中的SRC_TAG_LO透传过去决定Rx flow，注意此处必须根据这个来决定flow ID，并不是像你说的那样根据Rx channel序号来决定。
其他由pktDMA管理的外设，每个指定的flow ID方式都不一样，具体还得参考相应的手册，如NETCP如果接收的包需要经过PA，则首先需要配置好PA中每个PDSP的路由规则，路由规则中包括对最 终接收的包到底是由那个flowID接收的规定，如果以太网的包bypass PA及SA，则接收的包固定有flow22/23接收；对SRIO如果采用message方式，则在初始化的时候需要配置好相应的RXU_MAP寄存 器，SRIO会从接收包中提取相应的srcID等信息与MAP寄存器匹配得到相应的flowID。这些信息都在相应的NETCP及SRIO手册中有描述。“
loopback的时候，我知道是用descriptor中的SRC_TAG_LO，来指定收包时的RX flow，这个应该是corepac核间通信时只在QMSS内部收发包时用的吧？
而后面提到的”其他由pktDMA管理的外设，每个指定的flow ID方式都不一样“，比如主楼中截图里边的PA收包，RX flow到底是怎么选定的flow index，这个是什么在什么地方配置了？我在PA的手册里边压根没有找到跟这个相关的配置，还请专家们明示，多谢啦！

首先请明确Rx flow是PKT DMA模块的概念，而整个SoC中有若干个不同的PKT DMA模块，上述你应用的帖子中提到了两个不同的PKT DMA模块，一个是QMSS 内部的infrastructure PKTDMA,另一个是NetCP的PKT DMA。两者的机制是类似的，但是是两个独立的模块，配置的寄存器基地址都是不同的。infrastructure PKTDMA的Rx flow仅用于infrastructure PKTDMA的接收配置，NetCP PKT DMA的Rx flow仅用于NetCP PKT DMA的接收配置。
   其次，NetCP PKT DMA的RX flow是在PA的路由规则中配置的，文档上没有详细接口，请参考PA LLD的源代码。比如
paReturn_t Pa_addMac  (  Pa_Handle          iHandle,
                         int                index,
                         paEthInfo_t       *ethInfo,
                         paRouteInfo_t     *routeInfo,
                         paRouteInfo_t     *nextRtFail,
                         paHandleL2L3_t    *handle,
                         paCmd_t            cmd,
                         uint16_t          *cmdSize,
                         paCmdReply_t      *reply,
                         int               *cmdDest )
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;

非常感谢您的回复，最近忙其他的事情，好久没有关注这个问题了，这两天切到这个问题上了
看了您的回复豁然开朗，之前这个问题一直没想明白，原来居然是这个样子的
今天看了一下代码，发现如下：
/** CPPI maximum number of CPDMAs */
#define CPPI_MAX_CPDMA 3
这是第一个地方
The CPPI Low level driver supports the following CPDMAs:
• Serial Rapid IO
• Antenna Interface
• FFT Co-processor
• Packet Accelerator SubSystem
• Queue Manager SubSystem
这是第二个地方，cite from 《CPPI/QMSS Low Level Driver Software Design Specification (SDS)》
从以上两个地方可以知道的是，硬件上CPPI一共有5个：SRIO、AIF、FFTC、PASS、QMSS，
pdk代码中有SRIO、PASS、QMSS这三个module中的pktdma，AIF和FFTC的代码中没有涉及到
那么问题来了（呵呵），请问一下，各个subsys中的pktdma的寄存器的implementation都是一样的吗？
各个pktdma仅仅是基地址不一样、其他各个寄存器偏移和内容都是一样的吗？

谢谢了哈

是的，不同硬件中的pktDMA的硬件机制一样，所以配置使用都是一样的，各个寄存器的定义及地址偏移都是一样，只是寄存器基地址不一样。
                                                                          

多谢多谢，顺便再请教两个问题哈，就是数据流处理过程中packet在各个module之间交互方式的问题。
第一个问题：PA、SA、GE之间的packet交互，都是通过QMSS进行交互的吧，这个很好理解，问题是PA内部的各个PDSP之间的packet交互如何进行？
比如GE收进来的包交给PA处理时，如果L2、L3、L4都需要进行比对处理，是GE先将packet放到PDSP0(L2)的queue 640中，然后PDSP0比对OK之后，再放入queue 641中去，以此类推，还是怎么处理的啊？
我看寄存器发现PDSP有个mailbox slots寄存器，这些个寄存器应该也是可以用于PDSP之间进行交互的吧？
如此一来，是不是各个PDSP之间的交互方式有两种，一种是通过QMSS，一种是通过mailbox？

第二个问题：CPSW配置寄存器，描述如下截图

是不是可以通过配置CPSW，将GE收进来的包送到queue 640、queue 641、queue 642、queue 643、queue 644、queue 645以及bypass PA？
谢谢啦

因为以上两个问题在文档中找遍了，也没有找到确切的描述，自己猜测是这个样子，又不确定，只好请教一下专家了，如果有确切描述的文档，还请明示

1. MailBox 是NetCP与core之前的配置接口(VBUSP总线），目前NetCP与Core之间没有用到，而是基于QMSS的描述符/包的传递（VBUSM总线）。而QMSS中的PDSP如accumulator, QoS的配置则基于mailBox.NetCP的PDSP之间的交互过程没有通过PKTDMA，数据包实际存在于PDSP memory中，PDSP之间不没有包拷贝，只传递地址。只有与HOST（DSP or ARM）交互的情况下才会用到640~648.
2.你的理解正确。但是注意其实只有配置为PDSP0和PA bypass(channel 22/23)才真有意义，直接把包发到其他的PDSP未必能正常处理。

非常感谢，现在终于明白了
Please note that it is okay for submodules within a module to
communicate with each other without using the queue manager. For example the
PDSP submodules in the PA can communicate with each other directly without using
the queue manager, but if a PA PDSP wants to route a packet to the SA for processing,
it must use the queue manager
NetCp的文档中有这段描述，原来最开始读这个文档的时候，概念不清晰，这段没什么印象，今天重新看了下，
这个描述还是相当清晰的。
另外，看了您的回复，我原来对于第二个问题的大流程理解没问题，但是细节上应该是GE收进来的包传递给
PDSP0处理的时候，应该是将以太网包的包头部分写入PDSP0中吧（至于具体的内容还需要再研究一下GE和PA的交互），
然后PA处理完，到最后才生成一个packet，并推到queue中去，而非GE将收进来的包放入queue 640中吧。
in a word, many thanks!