Linux/AM5728: Priority packet handling

Hi,

We don't an example currently, we will investigate to see if we can find some examples though. One question after discussing your post is how many channels did you want to prioritize? Is this dual mac mode or switch mode? And is your application capable of using VLAN tagging for prioritizing packets?

Best Regards,
Schuyler

Hi,

I have to use the dual mac mode, because we have 2 configs, an AM5728 with one Ethernet Port and another with 2 Ethernet Ports. The first config with one Port is using every Ethernet stuff like PROFINET, TCP, etc. The second config with 2 ports will be using the dual mac mode, because we want to use the second port as a seperat network connection. So I guess for the first config the dual mac mode isn't that important, because of using only 1 Port, but for the second config it is neccessary.

It would be good to have at least 2 channels to prioritize my egress packets and if it also possible the ingress packets. We have the problem, that we don't know how to filter important Real-Time packets and give them a high priority. We dont want to use VLAN tagging for external connections. We dont offer the VLAN functionality. But if there is a possibility to use VLAN only internal for reordering the sending/receiving queue, would also be nice to know how that works.

I was just hoping that that this packet priority handling could be the solution for our problem.

No ideas? I thought the tool traffic control could help, but it was not working. How can I use this the right way:

24.11.4.8.3 Packet Priority Handling
Packets are received on three ports, two are CPGMAC_SL Ethernet ports and the third port is the CPPI
host port. Received packets have a received packet priority (0 to 7, with 7 being the highest priority).
The received packet priority is the port priority for untagged packets, and the actual packet priority for
priority tagged and VLAN tagged packets. The received packet priority is mapped through the receive
ports associated packet priority to header packet priority mapping register to obtain the header packet
priority (the CPDMA RX and TX nomenclature is reversed from the CPGMAC_SL nomenclature).
The header packet priority is mapped through the header priority to switch priority mapping register to
obtain the hardware switch priority (0 to 3, with 3 being the highest priority). The header packet priority is
then used as the actual transmit packet priority if the VLAN information is to be sent on egress.

If I use one of the two CPGMAC_SL ports, there would be only the direction between this and the host port. How can I configure these ports and how can I say which packet has which priority?
Is it even possible in dual mac mode or only in switch mode?

Hi Kevin,
I apologize for the delay, I have been out of the office for the last week. When I discussed this with the driver maintainer the only potential solution was using VLAN due to its incorporation of priorities. VLANs are used internal to the switch to provide the dual capability, I don't know if this method can be extended yet. I will discuss with him again and respond tomorrow.

For the topology you are describing, the PRU port would be restricted to PROFINET and similar protocols? The CPGMAC are the ports that you want the packet send prioritization to occur?

Best Regards,
Schuyler

We dont use the PRUs. Our PROFINET stuff is working on the second ARM core over the CPGMAC port. Since we dont know how to prioritize, it is hard to avoid jitter of the cyclic data. So thats our use case, how can we prioritize specific packets e.g. PROFINET cyclic traffic to avoid jitter.

FYI. There is set of patches in the Linux Kernel main line which enables multiq and shapers for cpsw.

-- net: ethernet: ti: cpsw: add .ndo to set per-queue rate
git.kernel.org/.../cpsw.c
-- net: ethernet: ti: cpsw: add ethtool channels support
git.kernel.org/.../cpsw.c
-- net: ethernet: ti: cpsw: add multi queue support
git.kernel.org/.../cpsw.c
-- [v5,net-next,0/6] net: ethernet: ti: cpsw: add MQPRIO and CBS Qdisc offload
patchwork.ozlabs.org/.../

More information about traffic2queue mapping you can get from "tc/qdisc/filter" tools description. Example:
tc qdisc show dev eth0
tc qdisc add dev eth0 parent root handle 100: mqprio num_tc 3 map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 6@2 hw 0
tc qdisc add dev eth0 clsact
tc filter add dev eth0 egress protocol ip prio 1 u32 match ip dport 5001 0xffff action skbedit priority 3
^ above will map TCP/UDP traffic to port 5001 to priority 3 -> to traffic class 0 -> TX queue 0
^ clsact might not be supported in your kernel version

Also, you can find additional description about priorities handling in www.ti.com/.../spruhz3a.pdf
section "2.3.4 Priority Mapping and Transmit VLAN Priority" - this is for different SoC, but operational principles are the same.

Note. As per my knowledge - AM57xx CPSW can use only priority tagged/vlan tagged/port priority to assign packet priority (for example : untagged packet priority will not be set to 7 if packet was sent through TX CPDMA channel 7, but CPDMA can be configured to work in fixed priority mode and will process channel 7 first).

For the first look it seems these patches are only for a newer version of the kernel, is that right? We are using the Kernel version 4.4.41 of the SDK 3.3.0.4.

It seems that these patches aren't that easy to merge to my kernel. It is not possible for me right now to upgrade the kernel version.

I am still trying to understand how it works to use the mapping of packets into the transmit queues. I will try to debug the cpsw driver now, but it would be very helpful to get some help here.

Hi,

Before you go through the effort of the backport I would like to recommend trying the patches against the latest SDK or even top of the TI Linux kernel tree to see if your requirements will be satisfied with the proposed patch set. Do you have a TI AM5728 GP EVM or IDK board by any chance?

You mentioned that you cannot change kernel versions, is there a reason that you can publicly disclose why this is not a possiblitly?

Best Regards,
Schuyler

Hi Schuyler,

we are not allowed for now to make a change for the kernel version and trying the patches seems like a big merging in the kernel, which could be dangerous for our current applications.

I am debugging the kernel right now, and I can see that there are a lot of unused channels for receiving and transmitting. If I see right, there are 32 channels for each port, that means 16 for receive site and 16 for transmit site. With default settings, there will be only 1 channel each used for receive and transmit.

Code of cpsw.c
cpsw->txch = cpdma_chan_create(cpsw->dma, tx_chan_num(0),
cpsw_tx_handler);
cpsw->rxch = cpdma_chan_create(cpsw->dma, rx_chan_num(0),
cpsw_rx_handler);

Only channel 0 will be created. Is the old kernel code not able to use more channels than that?