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.

TMS320C6678: Pa_addPort() wildcard for ports not matched by other rules

Part Number: TMS320C6678

I have a system with a network stack running on core0.  Currently the PA LLD Pa_addMac() rule routes all mac address matches to a qmss queue for core 0.  I want to add rules to filter UDP packets received on certain ports to other queues and send packets received on other ports to my qmss queue for core 0.  How can I add a fallthrough/else rule to the L4 classify engine?

  • Hi Katia,

    1. The packet dispatch happens based on the "match" rule and "next route fail" rule for the packets that did not match. (you can continue parse for match rule or fail rule OR any time route the packet to HOST) - all are configurable. Please refer to the PA API documentation for Pa_addMac (Or Pa_addMac2) for details on adding mac entry (Please refer to other APIs for adding IP and Port - based on your needs).

    2.  Please note that in adding all the rules, the catch up rules (generic) are added first and more specific rules are added next for the PA.

    You can refer to below documentation on the order:

    So, your general catch up rule for UDP (you can have any UDP port match to qmss queue for core 0) as the first rule added and on top of that add the specific udp port match to route to other queues to meet your needs. This should serve as a wildcard match for ports that are not matched by other rules.

     

  • Thank you Aravind.

    Does Pa_addPort with 0 for the port number act as a wildcard?

    The doxygen for Pa_addPort states that the order of the rules in the L4 classify engine do not matter.  You appear to imply the order does matter.  Which is correct?

  • Hi Katia,
    The doxygen for Pa_addPort() is correct. (The order of the rules in the L4 classify engine (LUT2) does not matter).
    Sorry, for implying this in my earlier thread. The order matters only for LUT1 lookup and not for LUT2.

    On your question: "Does Pa_addPort with 0 for the port number act as a wildcard?" - No, UDP port '0' does not act as a wildcard.

    For your need, please find the revised suggestion. Let me know if this resolves your need.

    I think you can do below.

    I am providing the details for one mac id (MAC-ID1) and one UDP port (UDP-PORT1).
    Probably, you need to have more such rules for more MAC and UDP port matches.

    Pa_addMac() Pa_addIp() Pa_addPort()

    - ethInfo with MAC1



    -ipInfo ('0' - don't care)
    and link to MAC Handle


    - specific Port (link to IP handle)

    - routeInfo: 
    Continue Parse 
    -routeInfo: 
    Continue Parse
    - routeInfo:
    route to other queues
    - nextRtFail: 
    Don't care
    -nextRtFail:
    fallthrough/else rule
    (qmss queue for core 0)
    - There is no next fail rule here.

    The above should get the enhancement for your current Pa_addMac() rule.

  • Hi Katia,

    Please let me know if this resolved your issue. I think you should be good with above proposed changes

    Thanks

    Aravind

  • Thank you Aarvind, I think using the nextRtFail on Pa_addIp() is the fallthrough/else I was looking for.  I'll need to test this.  The only place I see mention of this is in the header/Doxygen.  This is not mentioned in the Packet Accelerator User Guide (SPRUGS4A).

    What purpose does Pa_addPort()'s linkHandle parameter and Pa_addIp()'s prevLink parameter serve?

    Is there a document that explains the PA LLD?  (Similar to the CPPI_QMSS_LLD_SDS.pdf)

  • Hi Katia,

    Thanks for confirming above suggestion works for your (I understand you need to test this still).

    PA LLD documentation is all via the doxygen APIs. The interface header file (ti/drv/pa/pa.h) has all the details documented. 

    The prevLink parameters (for Pa_addIp) are used link the previous MAC (L2) or previous IP (L3) if you have inner IP.

    Similarly, the linkHandle in Pa_addPort() is the L3 handle that is linked to the destination port.

    These are documented in Pa.h file that I mentioned before.

    The link handle, makes it possible to match specific MAC -> Specific IP -> Specific Port rule to be linked in the PA add rules.

    Example:

    When you call Pa_addMac() you get the L2 handle created and passed to the application, provide that handle as prevLink handle for Pa_addIP().  You would get L3 handle created by Pa_addIP(), which you can provide as prevLink for Pa_addPort().

    This makes sure you would be matching the correct MAC, IP and PORT. In your case, IP entries are '0' indicating they don't care fields.

    So by above configuration, you get

    1. Specific MAC -> Any IP -> Specific Port goes to a different queue.

    2. Specific Mac -> Any IP -> Other Ports (fall through cases) goes to qmss queue 0.

          

  • Hi Katia,

    Please mark the issue as resolved, if your issue is resolved with above suggestion.

    Thank you very much!

    Regards,

    Aravind

  • Thank you Aravind.  I was able to demonstrate this approach

  • I would note one modification I had to do was to change Pa_addMac()'s nextRtFail to route to qmss queue for core 0 to prevent ARP packets to my MAC address from being lost.

  • Hi Katia,

    Glad to hear back from you that you were able to resolve your issue with the above approach.

    Thanks,

    Aravind