RE: [ixp1200] Control of microengines and threads++
Going strictly from memory, here is what I remember 1) How are the microACEs distributed among the microengines when using a default configuration file? I am unable to find any documentation on this subject (The ixsys.* files are generally poorly documented :)). The distribution is based on the number, speed, and direction of the interfaces. For each 100Mb/s interface, two microengines are allocated for all microblocks marked as "receive side", and one microengine is allocated for all "transmit side" microblocks. For every 4 10Mb/s interfaces, one microengine is allocate for the receive side and one microengine for the transmit side. 2) How can I control this distribution? Can I give any directives in the configuration file to load an ACE on two engines, or is this done programatically, i.e., when initializing the ace from the core? Again from memory, if you use the ixsys config utility unmodified, then I believe you are limited to the above distributions. However, the ixsys config is simply a utility built on top of the resource manager APIs, so it is possible to write your own ixsys config utility (or modify the existing one) to perform your own custom mapping. 3) How about the number of threads running on the engine? What is the default and how can I control it? The control of the threads per-microengine is embedded in the source code itself. That is, both the resource manager and the ixsys config utility simply load the microengine with a single image and start all threads executing. That said, if you, for example, configured fewer than 4 10Mb/s ports on the receive side microengine, the ingress ACE code would likely kill the execution of some of the threads (however, it has been a very long time since I looked at this code so if this is critical to you, be sure to read the code). 4) Does the IngressACE do any processing of packets, or does it only define the macros that I use in my dispatch loop? According to the design documents and the source the latter seems to be it, but I'd like to be 100% sure. I guess it depends on your definition of "processing". The ingress ACE core component does not process packets. The ingress ACE microblock reassembles mpackets into a single packet and checks the destination MAC address of the packet to ensure the packet belongs to the system. 5) Does anyone know how many cycles it takes the egress to transfer a 1024 byte large packet from SDRAM to the link? :) -Or where can I find information about how the egress really works? I don't know the transfer time. As a shameless plug, if you want to read about transmit on the IXP1200 you could check out the "IXP1200 Programming" book, Chapter 9. erik ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erik J. Johnson Intel Research & Development erik.j.johnson@intel.com NOT SPEAKING FOR INTEL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Thu, 2004-07-22 at 21:57, Johnson, Erik J wrote:
Going strictly from memory, here is what I remember
Hi, Mr. Johnson. Thanks for your reply. I have your book btw. :)
I do not understand this! The chip has 6 µengines. If two µengines are allocated for the "receive side" and 1 is allocated for the "transmitt side" per interface. Then, 3 µengines are needed per interface. Does that mean that 4 100Mb/s interfaces will require 12 µengines? Then you say that 10 Mb/s interfaces require 2 µes each, that means 8 µes? Seems I'm short of a few µes, or more likely; I'm getting this all wrong!
When you say ingress ACE microblock, do you in fact mean the EthernetIngress macro? (e.g., SlowIngress macro).
--
Øyvind Hvamstad
participants (2)
-
Johnson, Erik J
-
Øyvind Hvamstad