Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in
C
codes
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 38
    • Issues 38
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 8
    • Merge Requests 8
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • codes
  • codes
  • Issues
  • #60

Closed
Open
Opened Jan 14, 2016 by Jonathan Jenkins@jenkins
  • Report abuse
Report abuse

overhaul mapping methodology for lsm/resource/modelnet

Currently, the APIs used for sending messages to (or through) the LPs depend on an implicit mapping to LP-IDs in the same configuration group as the caller. Where configuration "offsets" are concerned, a hack is performed that simply modulo's the caller offset against the number of callee offsets. For trivial 1-1 or N-1 mappings this is OK but anything more and this is insufficient. Case in point, connecting different lp types to dragonfly terminal LPs.

Need to think of a way to provide better mapping flexibility, preferably without completely overhauling how we do mappings.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
2
Labels
CODES task
Assign labels
  • View project labels
Reference: codes/codes#60