P4080 PCIe Adapter SDK User Guide Production Release

Freescale Semiconductor
3.2 Run-to-Completion USDPAA Application Execution Model
Both the stand-alone host mode and the EP mode support a run-to-completion model of execution of the
USDPAA applications which is detailed in this section.
The full run-to-completion use case is defined by the following characteristics:
• No more than one USDPAA thread is used per core. Not all cores need have a USDPAA thread,
however.
• Cores hosting USDPAA threads may be configured to run nothing in user space other than that
core’s USDPAA thread. For example, the kernel parameter “isolcpus” can be used. This parameter
prevents the Linux scheduler from running a thread or process on an isolated core unless the
scheduling mask of that thread or process is explicitly set to include the isolated core. USDPAA
does not require isolation architecturally, but it may be used if the system goal is to, at least mostly,
dedicate a core to running a single thread. Also, polling (see below) is wasteful if others threads
are to run on the same core as the USDPAA thread.
• In run-to-completion, USDPAA threads poll their portals. Polling generally implies that the
USDPAA threads will always be running or ready to run. It would be unusual to have other threads
scheduled on the same core.
• Often, one thinks of the USDPAA threads as “workers” able to process any form of “work”
delivered via QMan messages. In this model, the QMan scheduler can be used as a general “work”
scheduler rather than relying on the Linux scheduler for this purpose.
Figure 3 illustrates the use of QMan in multi-step processing of a network frame:
• Frame arrives at FMan.
• Frame is processed by a core and sent to SEC.
• SEC further processes the frame and returns it to a core, possibly a different core.
• Core sends frame to FMan for egress.
The numbers in the figure show the steps in the progression of a frame through the example.
The QMan scheduler determines the priority of processing at each step.
Specific types of “work” are carried by specific frame queues, the heads of which reside in specific QMan
channel work queues. QMan inter-class scheduling operates at the work queue level and determines the
order in which the messages that carry the “work” are delivered.
Work queues within QMan pool channels can be associated with classes of “work.” Portals’ QMan
dequeue masks determine the set of channels from which the portal will dequeue. Since the portals are
affine to cores, this determines which cores are configured to process which classes of work. Even the
number of cores can be adjusted by changing the masks.
© Freescale Semiconductor, Inc., 2011. All rights reserved.
Freescale Confidential Proprietary Page 10