Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
F FLAG
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 7
    • Issues 7
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ras-devel
  • FLAG
  • Merge requests
  • !2

Merged
Created Jun 11, 2019 by Mitch Burnett@mcbOwner

Net thread mcnt processing logic improvements

  • Overview 0
  • Commits 11
  • Changes 10

Mcnts (m-counts) are the moving force in this processing pipeline. As packets are received from the network the net thread processes them and determines where they go in shared memory based on the mcnt in the packet header.

The old processing logic in the net thread did not handle late packets very well and as a result we would get pipeline hangs or lockups where threads were waiting on each other to fill and free blocks. In this case the net thread would become stuck in a logic flow control loop because we had no logic to handle late packets and re-initialize the buffer when we feel sufficiently behind.

Our logic was sensitive to any sort of processing jitter in all of the processes (and OS and kernel tasks) and so when any process took longer than normal before the net thread was able to execute again the net thread would fall behind. So these changes make the net thread more reliable and robust despite these forces. Meaning that other issues (RTBF taking a long time or virtual memory dump issue in the kernel) are still happening but we don't hang because this new logic detects this and re-inits the pipeline (i.e., some loss of data).

In the brief testing we have done with these changes it seems that the goal is largely accomplished but there are yet more changes and improvements that can be made to the pipeline. For example, we are still only using 4 input blocks on the net thread and ping-ponging back and forth (e.g., actively fill 2 while 2 are being emptied) and we could write better code that utilizes the ring buffer structure more effectively.

Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Source branch: net-thread-improvements