Configuring PA Routing

I've fixed the problem myself.

Seems that the fail rule DOES NOT apply to the current rule you are adding, but instead the next one in the flow.

If I change the rule above to pass onto the next layer and add an IP address match (with a pointless discard fail rule), it then correctly invokes the previous fail rule when both MAC and IP do not match.

May I suggest that this should be made very clear in the API documentation and also that a comprehensive manual with varied examples is produced for the PA.

The PA would be a valuable tool if it was explained in layman terms.

Hi Simon,

Summarising the external discussion on your additional requirements for comment by my colleagues. In your second more complex routing case where you need to cascade rules aimed at distributing packets to several queues. In your scenario there are 2 packet queues called 'local' and 'link'. The operations in order are:
    a) If broadcast packet (destination MAC = FFFFFFFF), route packet to multigroup (local and link).
    b) If destination MAC = the device, route packet to local queue.
    c) Else all other packets route to link queue.

An example in pseudo code is as follows:

receive packet

if MAC is broadcast then 

 route to 'local' AND 'link' else

 if MAC is 'local' then

 route to 'local'

 elseif <rule> = 'Link1' then

 route to Queue 'link1'

 elseif <rule> = 'Linkn' then

 route to Queue 'linkn'

 :

 else

 route to Queue 'link default' 

 endif

endif

You will in theory add :

rule -. dest == device, route to host, queue deviceQ

rule - dest == link1, route to host, queue link1Q

rule - dest == linkN, route to host, queue linkNQ

rule - everything in routeInfo set to 0 as "don't care", route to host, queue linkDefault. -> NOTE: This has to be the last rule set, because if not all packets will be routed to queue linkDefault.

For the purposes of completeness there are a few areas in the documentation which provide more insight :

• information can be found in the doxygen documentation of the PA LLD under Modules->Functions (pa_AddMac, pa_AddIp)
• and also see doxygen pa_AddMac->order for information on rules order dependence .

It would seem that in theory you would simply need to add a 3rd rule for destination MAC 00:00:00:00:00:00 (i.e. all packets getting that far) to route to link queue, but you in fact can't add this as it is deemed to be less specific a rule than the previous rules. I know you tried this but it does not does not work correctly for this reason.

Hopefully one of multicore team will be able to follow-up with wisdom on how to achieve the functional routing that you need.

Regards,

Garry

Hello.

Please find attached the file sub10_pa_test.tar.gz which is a modified copy of the TI emac example.

This version has two packet queues (gRxQHnd for packets destined for the device and gRxLinkQHnd for all other packets) and applies the following PA rules in the following order:

1) Configure Multi Group with the 2 queues. 

2) Add a MAC address rule for broadcast packets (destination MAC FF:FF:FF:FF:FF:FF) to route to the multigroup else goto the next rule.

3) Add a MAC address rule for the local MAC address of the unit to route matching packets to gRxQHnd else all other packets to gRxLinkQHnd.

These rules are applied successfully. The code then sits in a loop handling any received packets on either queue and incrementing counters.

With these rules, gRxQHnd receives both broadcast packets and packets matching the MAC address of the system. However, gRxLinkQHnd only receives broadcast packets.

Therefore I surmise that the else condition for rule 3 does not work.

I have made the minimum amount of changes possible to the example code, so it should be easy to see what I've changed.

Any help you can give to get this working will be appreciated.

Thanks

The toolset we are using for this is:

bios_6_34_02_18

ipc_1_25_00_04

uia_1_01_01_14

cg_xml_2_30_00

mathlib_c66x_3_0_1_1

xdais_7_21_01_07

dsplib_c66x_3_1_0_0

mcsdk_2_01_02_05

xdctools_3_24_05_48

edma3_lld_02_11_05_02

pdk_C6678_1_1_2_5

imglib_c66x_3_1_1_0

TI_CGT_C6000_7.4.2

I have run this on silicon rev 1.0 and 2.0 C6678 EVMs and on our own custom board rev 2.0.

Hi Simon,

I was pinged in to take a look at this yesterday. I also modified the emac example to do my tests, and I took a look at the project you posted. Attached in this post is my project; it's a bit crude, but I hope it'll help you (and me) to debug further.

About my project:

• It's in loopback mode. So the EVM is sending packets to MAC addresses, and that gets looped back on the receive side to get processed by the PA
• No interrupts, I'm polling queues for packets
• I did not define queue handles; I directly used queue numbers (since I'm just doing a proof-of-concept)
• PA rule #1: catch all packets that do not match other rules, put these packets to queue 896
• PA rule #2: Packets with destination 10-11-12-13-14-15 goes to queue 704
• PA rule #3: Packets with destination aa-bb-cc-dd-ee-ff goes to queue 705
• PA rule #4: Packets with destination 66-77-88-99-12-34 goes to queue 706
• PA Config_BroadcastMultiGroup: I copied this from your project. mRouteIndex is 0, and the two queues are 708 and 709
• PA rule #5: Broadcast packets are routed to mRouteIndex 0
• I changed gRxQHnd to 7296 instead of using a high-priority queue. This makes no difference, I originally just wanted to make sure I can use any queue for the CPPI flow
• SendPacket is modified to take a parameter to send to specific MAC addresses. Addresses I coded in are: 10-11-12-13-14-15, aa-bb-cc-dd-ee-ff, 66-77-88-99-12-34, FF-FF-FF-FF-FF-FF, 90-80-70-90-80-70
• I send 20 packets to each of the addresses previously mentioned. A total of 100 packets are sent, a total of 120 packets are received (polled from the queues).

Hello Ivan.

Thanks for the example, I think I have got this to work in our product, but will know for certain after a bit more testing.

I think the problem was my misunderstanding of what exactly goes on in the PA and I wasn't aware that the rules had to be applied in reverse order.

Following this, I have a new question. In the example, you routed packets by MAC address in rules 3 and 4. Whilst I do need to keep the other rules as MAC address rules, I need rules 3 and 4 to route to separate queues based upon the PCP bits only from a VLAN tag (for quality of service).

I assume I would need to use Pa_addCustomLUT1?

Are there any examples or documentation on how to do this?

Thanks.

Hi Simon,

Can you clarify the VLAN aspect a bit as I am not sure I understand your requirements:

• Your use of the PCP bits is to re-order the packets on each VLAN queue and process / forward ota based on highest priority first ?
• You want to run multiple VLANs against a MAC, each assigned and routed to a different queue ?

Regards,

Garry

We will be organising packets into multiple queues based on priority.

The priority is determined by the PCP bit field only in the vlan tag. We are not interested in the vlan id and it will process multiple vlans.

Depending on the value of the PCP, we need to route to different priority queues.

So its yes to both the two points above.

Thinking about this further, I have another question that follows the above. We will allow users to change the priority of queues, so we will need to reprogram the PA, preferably without powering down the device. Is there a way to clear all the rules out of the PA?

Thanks.

Hi Simon,

on checking with Ivan and the team the PCP based prioritisation is not yet supported by the PA LLD. The current MCSDK (PA LLD version 1.2.3.3) enables routing based on VLAN ID and MAC but not yet PCP.

By modifying the SendPacket() function in the test code to add an 802.1Q 4 byte header and changing the rules stack-up I have confirmed that MAC + VLAN ID routing can be implemented using the paEthInfo_t and the vlan VID tag such that rules can be cascaded to match on the same MAC but with different VIDs directing to different queues. The 3 msb (PCP) are not however used and setting these has the effect of anything non-zero in the rules definition resulting in a no match - i.e packets ending up in queue 896 in this case.

There are however plans to implement PCP based routing in a future release of the PA LLD. We are checking with the MC SDK team on their plans.

Garry

Hi Garry.

Am I able to use Pa_addCustomLUT1 to do the check we want myself?

I'm not clear on how to use Pa_addCustomLUT1 as the documentation is not clear.

Thanks.

Hi Simon,

hopefully the new patch release we sent you has enabled you to implement the PA QoS rules routing to queues based on VLAN header PCP. Could you let us have some feedback as to whether this has resolved the issue and we can close the request.

We are hoping to include the necessary changes and sample code in a future release of the MCSDK.

Regards,

Garry

Hi Garry.

I apologise for the delay replying, we have been very busy this last week.

The supplied patch covers our needs for our first release.

We have had brief discussions here on what we would like to do for future releases which would include handing multiple vlan tags. Is this something the PA can already deal with?

Also as I mentioned previously, we will need to be able to change the PA rules without powering down the system. Is there a way to clear the rules?

Thanks.

Simon,

We have had brief discussions here on what we would like to do for future releases which would include handing multiple vlan tags. Is this something the PA can already deal with?

Is this something that you cannot add multiple rules for?

Also as I mentioned previously, we will need to be able to change the PA rules without powering down the system. Is there a way to clear the rules?

Have you tried Pa_delHandle? 

-Ivan

Hi Ivan.

We will want to support double vlan tagged packets (http://en.wikipedia.org/wiki/IEEE_802.1Q#Double_tagging). I can't see how the current PA can handle this.

I will give Pa_delHandle a try. However we would like to be able to clear the whole PA out without having to remember the handles.

Thanks.

Gary,

Thank you for the updated PA fw and example code.

I have used the updated PA fw and API to implement a PA rule that routes packets based on PCP bits (0-7) in VLAN tagged packets.

The good news is this does route packets based on priority into Qn to Qn+7 as per the example. And untagged packets are routed by default into Qn with the same rule (lucky bonus?). We do have to use a single freeQ for all 8 QoS queues - but that’s OK.

If I use the new Pa_addMac2 for all our PA rules though (it should be backward compatible) - I find that when we come to add our broadcast multiroute, although the Pa_configMultiRoute succeeds - we don't see a response from the PA once we push the command using Qmss_queuePush.

I'll summarize our PA config that fails:

1. add QOS rule using Pa_addMac2 (catchall with pa_ROUTE_INFO_VALID_PRIORITY_TYPE)

2. add MAC dst match rule for our mgmt MAC using Pa_addMac2

3. add bcast multitoute using Pa_configMultiRoute (2 queues as dest)

4. add mac match on bcast using the multiroute index from 3. using Pa_addMac

5. add exception route using Pa_configExceptionRoute.

If I change 2. to use the old API: Pa_addMac, then the remaining steps configure the PA as expected. Otherwise - step 3 fails with no response from PA.

Any thoughts?