TMS570 EMAC multiple DMA Channels on the same interface

Hi Paolo,

  I think you kind of answer your own questions for the first two. Yes, you can use different channels for different type of frames and you will need to divide the CPPI RAM accordingly. Below is an excerpt in the userguide.

Eight channels are supplied for both transmit and receive operations. On transmit, the eight channels
represent eight independent transmit queues. The EMAC can be configured to treat these channels as an
equal priority "round-robin" queue or as a set of eight fixed-priority queues. On receive, the eight channels
represent eight independent receive queues with packet classification. Packets are classified based on the
destination MAC address. Each of the eight channels is assigned its own MAC address, enabling the
EMAC module to act like eight virtual MAC adapters. Also, specific types of frames can be sent to specific
channels. For example, multicast, broadcast, or other (promiscuous, error, etc.), can each be received on
a specific receive channel queue.

Hi Charles

Thank you for your quickly reply.

I can see that you have copy and paste an extract of RM.

Can you, please, answer my 3 questions?

Thank you in advance.

Paolo

Paolo,

We don't have as much expertise in the IP stack as maybe you expect - so can only give general answers. But will try:

>>Q1: Which are the advantages to use separate channels for the same MAC/IP interface? (I suppose a dedicated FIFO for each kind of communication).

I think this gives you a tool in managing quality of service. Not only in terms of processing priority but also in an embedded system where you are memory limited, the available buffers you allocate to one channel don't get used up by the other channels.

>>Q2: To do this, is it necessary (i think yes) to divide the CPPI RAM of descriptors in 3 parts, in order to separate each part for each channel?

I don't think it's got to be divided into 3 EQUAL parts. You submit the base address of each descriptor to the queue so it's not like there is a dividing line somewhere in the RAM.

>>Q3: Which is the best way to do this with lwip stack? Is it suitable to add 3 interfaces (netif) instead of only one?

Definitely this one is out of our area of expertise. We've got only an lwIP demo and don't have the expertise to support lwIP.
If you can get support on this from the lwIP community that's great otherwise maybe you might want to look at a commercial option with better support.

One thing I will say as a hint is that this same Ethernet IP with CPPI is used on many TI devices including some of the DSP and Sitara parts that have been on the market for a long time. So if you find out how someone solved this problem say on an AM18xx the same or similar solution may be applicable to this Hercules part - because the CPPI DMA is integrated into the EMAC.

-Anthony

Thank you Anthony

Can you help me to clarify my following doubts:

1) There is a couple of registers MACSRCADDRHI/LO that seems to give the source MAC address in transmission. Then outgoing packet have this source address. Besides, there are another couple of registers MACADDRHI/LO indexable by setting the register MACINDEX. If we use multiple emac address it seems that only the LSB byte of the 8 indexed MACADDRHI/LO is used to address a specific DMA channel in both rx and tx. Is it correct?

1.1) Then, if we program the 8 indexed MACADDRHI/LO with same value but different only in the last byte per channel, can we assume that, in transmission, the source address visible in outgoing packet is modified according to the last byte of the selected channel? Think we are looking Wireshark on the PC.

1.1.1) I.e. we program MACSRCADDRHI/LO to xx-xx-xx-xx-xx-01 and MACADDRHI/LO  to xx-xx-xx-xx-xx-01 (with MACINDEX=0) and MACADDRHI/LO  to xx-xx-xx-xx-xx-02 (with MACINDEX=1). Then if we send a packet on the channel 1, could we expect xx-xx-xx-xx-xx-02 as our source address in Wireshark? 

2) Otherwise how could EMAC control the input packet dispatching toward the 8 DMA queue, if the destination address in incoming packets is always that set in MACSRCADDRHI/LO (only 1 address for all) ?

2.1) This is because the connected hosts can address our EMAC only by the MAC address present in the source address of our ARP reply. Can you please, details a reception example, that explain the queue dispatching on incoming packets? Please start by the Source/Destination addresses from an END to END communication, where an end device is our board.

2.1.1) Finally, if we use different MAC addresses, then we need different IP addressed (or different subnets). It's correct?

Thank you in advance

Paolo

Paolo di Paolo1 said:

1) There is a couple of registers MACSRCADDRHI/LO that seems to give the source MAC address in transmission. Then outgoing packet have this source address. Besides, there are another couple of registers MACADDRHI/LO indexable by setting the register MACINDEX. If we use multiple emac address it seems that only the LSB byte of the 8 indexed MACADDRHI/LO is used to address a specific DMA channel in both rx and tx. Is it correct?

Yes. But there is also a 'hash' for multicast .   See the TRM 29.2.11.4 Hardware Receive QOS Support

(29 may be a different chapter for your particular TRM so search for Hardware Receive QOS Support...)

Paolo di Paolo1 said:

1.1.1) I.e. we program MACSRCADDRHI/LO to xx-xx-xx-xx-xx-01 and MACADDRHI/LO  to xx-xx-xx-xx-xx-01 (with MACINDEX=0) and MACADDRHI/LO  to xx-xx-xx-xx-xx-02 (with MACINDEX=1). Then if we send a packet on the channel 1, could we expect xx-xx-xx-xx-xx-02 as our source address in Wireshark? 

You should check this to confirm, but I think the answer is no.   I believe that the 'source' address 6 bytes you see on wireshark is embedded into the packet that you submit.   Whereas the TRM mentions:

29.2.12.1 Transmit DMA Host Configuration
To configure the transmit DMA for operation the host must perform:
• Write the MAC source address low bytes register (MACSRCADDRLO) and the MAC source address
high bytes register (MACSRCADDRHI) (used for pause frames on transmit).

Paolo di Paolo1 said:

2) Otherwise how could EMAC control the input packet dispatching toward the 8 DMA queue, if the destination address in incoming packets is always that set in MACSRCADDRHI/LO (only 1 address for all) ?

I don't understand the question because the 'SRC" is for transmit not receive.

Paolo di Paolo1 said:

2.1) This is because the connected hosts can address our EMAC only by the MAC address present in the source address of our ARP reply. Can you please, details a reception example, that explain the queue dispatching on incoming packets? Please start by the Source/Destination addresses from an END to END communication, where an end device is our board.

Unfortunately the ARP part is a bit outside our area of expertise ...

Paolo di Paolo1 said:

2.1.1) Finally, if we use different MAC addresses, then we need different IP addressed (or different subnets). It's correct?

Same here - too high a level for me - more of a TCP/IP networking question.

Dear Anthony

Thank you for your time and patience.

1) The Multicast hashing is already perfectly working. Thanks.

Following your words i understood that:

1.1) MACSRCADDRLO/HI registers are used for transmission MAC address of pause frame. While MAC address in transmission frames other than pause frames, is written by software in the packet content (pbufs RAM).

2) MACSRCADDRLO/HI registers are used only for transmit and not receive, while 8 indexed MACADDRHI/LO are used only for receive (QOS).

Is it correct?

Value Added

In order to use multiple MAC addresses in transmission it is necessary to put different MAC addresses in each output packets.

In order to address this with lwip, it is necessary to define more netif, one per MAC address. Then it is necessary to use a different ip address for each MAC (sure!)

Finally, because on the TMS570 EMAC, the broadcast packets are drained on a single (configurable) channel, the network shall navigate the list of linked netif, finding the match IP address in order to anwer the ARP requests.

Do you agree Antony?

[ I know that ARP and IP are bad word for you :-) ]

For the lwip users i suggest to focus attention on the LWIP_ARP_FILTER_NETIF option and its dependences.

I will back with a test session result asap.

Thank you

Paolo,

For questions 1, 1.1, and 2 - yes I believe this to be correct.. this is what the TRM indicates.

To be 100% sure I would probably try changing the MAC address in the PBUF payload in RAM

in the experiment I'm showing you below and see if it appears in wireshark.  

It would be a little ambiguos without doing this test because the lwIP example sets the mac address source

register to the same address as it includes in the payload.    I don't have a wireshark setup to run this test

though..   but I think you could close this one out easily if you are setup.

Anyway the payload that is submitted to the MAC definitely matches the BOLD segment of the frame outlined in the

datasheet.   See below.   And the SRC mac address is included in that payload.

This is coming from the HalCoGen lwIP demo 03.00.00 on an RM57 HDK but probably the same on any board.

I put a breakpoint in the file 'hdkif.c'  in the function 'hdkif_transmit()' on the line 320    

--> EMACTxHdrDescPtrWrite(hdkif->emac_base, (unsigned int)(active_head), 0);

Break here.

You can see that the MAC adddress is included in the payload..

First see the MAC address:

Now see how it is included in the payload..  first 6 bytes are destination of 0xFF FF FF FF FF FF then followed by the MAC address.

Payload is being viewed in the memory display window at address 0x0800156A.

A simple experiment would be to change one byte of this and then run and confirm the change appears on the Wireshark capture too as prior to this the source address register was set to the current (unchanged) MAC address.. 

For the 2nd question - I think the above seems to confirm you would have to put a different MAC address in the payload at least to 90+% confidence and if you have wireshark setup you can finish the experiment in a few minutes.

But .. how to change lwIP is really above my level of expertise.   It isn't clear to me that simply instantiating multiple NETIF would do the trick because if you do that underlying there is only one piece of hardware and I believe it may get initialized over and over if you duplicate the NETIF.

This is probably a good question for the lwIP forum / user's group.   We have a demo but don't have the expertise to support the stack - sorry.

Best Regards,

Anthony