2026-Q2

2026-06-29（周一） Daily

🧠 今天记录

• 现有 flagcx 代码在空闲 cpu case 下虽然ttft 文档，但是确实存在与 old flagcx 相同参数下 ttft 会大 300ms ✅ 2026-06-29 旧 /workspace/liuda/pd_disaggregation/mooncake_conn/vllm-plugin/test-1-old-flagcx.log 新 /workspace/liuda/pd_disaggregation/mooncake_conn/vllm-plugin/test-1-new-flagcx.log 回归了三个改动（待画图）后发现 tebench 里面指定 64k 切分也会降低 latency

改之前：

最终tebench性能为：

🚀 今日TODO

• 对 https://github.com/flagos-ai/FlagCX/pull/504 内的代码消融了改动，分析为什么(tebench 不太需要 shard 分组再分给多个线程， 端到端 pd 分离需要多个 shard，因为 p2pengine 按照 shard 提供多线程资源)会出现 latency 降低反而 ttft 增加 https://infrawaves.feishu.cn/wiki/ZDlTwcP8TiIvE5kXPErcvhyMnTf ，解决问题后已经合入。 ✅ 2026-06-29
• [ ]

2026-06-24（周三） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• 调整 batch0 的机内 alltoall 调度（把自己拷贝自己的 cudaMemcpyAsync 调度到机内 batch0 的最后一次） https://github.com/sii-research/VCCL/pull/57 ✅ 2026-06-24
• 小 size 的 latency 优化 https://jwolpxeehx.feishu.cn/docx/DJandd7giocB4IxDQrrcEfWannc ✅ 2026-06-24
• [ ]

2026-06-23（周二） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• [ ]

2026-06-22（周一） Daily

🧠 今天记录

• 怎么处理 pin mem 在一步调用时候的 free，肯定不能再去 lauch 一个 hostfunc 去下 cudaFreeHost 操作。。。。如果按照累加，per-comm 的复用的话会有啥问题？？串行？

🚀 今日TODO

• [ ]

2026-06-11（周四） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• [ ]

2026-06-10（周三） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• 输出 vllm 文档 https://infrawaves.feishu.cn/wiki/S0GSwweqYiPiv5knJodc4TPVn7N?from=from_copylink ✅ 2026-06-10
• [ ]

2026-06-05（周五） Daily

🧠 今天记录

• scheduler 没拿到 kv block 的抢占策略，咋恢复的？

                    # The request cannot be scheduled.
                    # Preempt the lowest-priority request.
                    if self.policy == SchedulingPolicy.PRIORITY:
                        preempted_req = max(
                            self.running,
                            key=lambda r: (r.priority, r.arrival_time),
                        )
                        self.running.remove(preempted_req)
                        if preempted_req in scheduled_running_reqs:
                            preempted_req_id = preempted_req.request_id
                            scheduled_running_reqs.remove(preempted_req)
                            token_budget += num_scheduled_tokens.pop(preempted_req_id)
                            req_to_new_blocks.pop(preempted_req_id)
                            scheduled_spec_decode_tokens.pop(preempted_req_id, None)
                            preempted_encoder_inputs = scheduled_encoder_inputs.pop(
                                preempted_req_id, None
                            )
                            if preempted_encoder_inputs:
                                # Restore encoder compute budget if the preempted
                                # request had encoder inputs scheduled in this step.
                                num_embeds_to_restore = sum(
                                    preempted_req.get_num_encoder_embeds(i)
                                    for i in preempted_encoder_inputs
                                )
                                encoder_compute_budget += num_embeds_to_restore
                            req_index -= 1
                    else:
                        preempted_req = self.running.pop()

                    self._preempt_request(preempted_req, scheduled_timestamp)
                    preempted_reqs.append(preempted_req)
                    if preempted_req == request:
                        # No more request to preempt. Cannot schedule this request.
                        break

🚀 今日TODO

• [ ]

2026-06-04（周四） Daily

🧠 今天记录

• for loop 协程 一个线程管理上千并发连接

---

它具体在干什么

伪代码长这样：

while True: # 检查哪些协程的 await 已经有结果了（I/O 完成、timer 到期等） ready = 检查所有等待中的事件()

for 协程 in ready:
    协程.send(None)  # 让这个协程从上次 await 的地方继续跑
    # 协程跑到下一个 await 又挂起，控制权回到这里

---

举个具体例子

async def handle_request(): result = await engine_core.add_request_async() # ← 挂起 return result

1. handle_request 跑到 await，把”我在等 ZMQ 的响应”告诉 event loop，然后挂起
2. event loop 继续循环，去跑别的协程（比如另一个请求）
3. ZMQ 响应回来了，OS 通知 event loop “这个 socket 有数据了”
4. event loop 把 handle_request 放回 ready 列表
5. 下一轮循环跑到它，从 await 后面继续执行

---

本质

event loop 就是 I/O 多路复用的调度器，底层依赖操作系统的 epoll（Linux）或 kqueue（macOS）来同时监听多个 socket/文件描述符，有事件就通知对应的协程继续跑。一个线程，管理成百上千个并发连接。

• [ ]

🚀 今日TODO

• [ ]

2026-06-03（周三） Daily

🧠 今天记录

• 如果有空看一下 vllm/v1/sample/ops/topk_topp_sampler.py内，这个是前向 logits 产生后，进入采样层得到下一个 token。这里的 sampler 用了一堆手段 logprobs，把概率分布变为实际生成的t

🚀 今日TODO

• [ ]

2026-06-02（周二） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• 输出 flagcx connector 的 PR 测试报告 https://infrawaves.feishu.cn/wiki/T4Y7wcnKuiHBl7ktErKcr21ynPq?from=from_copylink ✅ 2026-06-02

2026-06-01（周一） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• vccl v2 分支打 tag，加上陈青的 notes 完成发版。 ✅ 2026-06-02
• flagcx 侧增加 RPC 服务，独立线程提供对外的远端 rkey 的交换保存。flagcx p2p engine 的接口封装为 python，上层 connector 更新为新的注册和传输方式。 ✅ 2026-06-02

2026-05-28（周四） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• 我现在/Users/joker/Desktop/project/baai/vllm/vllm/distributed/kv_transfer/kv_connector/v1/flagcx_connector.py直接使 用 flagcx_p2p 的新多 worker 的实现的话 我需要一个[Pasted text #3 +14 lines]的 rpc 服务的功能

2026-05-27（周三） Daily

🧠 今天记录

• nixl 和 mooncake 的 rkey 存储位置： nixl：

• topo

🚀 今日TODO

• [ ]

2026-05-25（周一） Daily

🧠 今天记录

🚀 今日TODO

• 完成 flagcx 内多后端多线程高性能 post wr/poll cq 方案设计 ✅ 2026-05-27

2026-05-19（周二） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• [ ]

2026-05-15（周五） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• [ ]

2026-05-12（周二） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• 陈默的 kv transfer benchmark跑通提 pr 并更新数据 ✅ 2026-05-15
• [ ]

2026-05-11（周一） Daily

🧠 今天记录

• nixl 走 mooncake 数据 ✅ 2026-05-11
• vccl v2 代码验证 ✅ 2026-05-11

1. 问题：syncCond 结构体, enqueue 会调用 ncclProxySaveOp → SaveProxy → ncclLocalOpAppend ，在 ncclLocalOpAppend 内看到 memcpy 去把 proxyOp 搬运到了一个 共享 的 pool 内（ proxyProgressInit 内创建到 shm 内）。这里就会出现 syncCond 在 rank0 的池子内的时候，rank1 来读就会 coredump。结论就是：syncCond 和 proxyOp 拆开管理就没问题，或者关闭 pxn

• vllm上层移除 cuda 调用 ✅ 2026-05-12

🚀 今日TODO

• vccl v2 代码验证 ✅ 2026-05-11

2026-05-09（周六） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• nixl 走 mooncake 数据
• vccl v2 代码验证

1. 问题：syncCond 结构体

• enqueue 会调用 ncclProxySaveOp → SaveProxy → ncclLocalOpAppend ，在ncclLocalOpAppend内看到memcpy 去把proxyOp搬运到了一个 共享 的 pool 内。这里就会出现 syncCond 在rank0 的池子内的时候，rank1 来读就会 coredump。暂时不确定为什么 226 版本没有问题
• [ ]

2026-05-07（周四） Daily

🧠 今天记录

• 听 mega-moe ✅ 2026-05-07
• 修复 pr ✅ 2026-05-07

🚀 今日TODO

• [ ]

2026-05-06（周三） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• 增加 iputBatch 后，对外依旧保留flagcxNetAdaptor_v1 的 abi 接口，内部将 flagcxNetAdaptor_v1 转换成 flagcxNetAdaptor_latest 来让 plugin loading 不会出现问题，以及支持 batchPut。 ✅ 2026-05-06
• 调整 flagcxIbAddEvent 放到 flagcxWrapIbvPostSend后面，确保统计的 completion计数是 req 被真实 post 后的 wr。 ✅ 2026-05-06
• 增加环境变量说明 ✅ 2026-05-06

2026-04-22（周三） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• [ ]

2026-04-20（周一） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• 分析 flagcxRmaProgressThread 效率问题 ✅ 2026-04-20
• vccl v2 内 cpu 侧调用优化 ✅ 2026-04-20
• 研究 vllm page attention 算子的原理
• 验证 cpu 侧优化后的 VCCL A2Av 性能⇒chenqing ✅ 2026-04-20

2026-04-17（周五） Daily

🧠 今天记录

• [ ]

🚀 今日TODO

• flagcx pr446 内 bugfree，修正了系统过载flagcxRmaProgressThread会丢掉 wr 的 case，已合入。 ✅ 2026-04-17
• 分析 flagcxRmaProgressThread 效率问题
• 分析vccl training json/nsys

2026-04-16（周四） Daily

🧠 今天记录

• debug flagcx connector ✅ 2026-04-16

• 【bug1】看到flagcxWaitSignal 报错raise RuntimeError(f”FLAGCX error: {error_str}”)

  • 确定了 error 码是 1，就是Unhandled device error ⬇️
  • 先增加了 comm 初始化 并发的隔离，未解决，但是代码保留 ⬇️
  • 然后怀疑是 context 用了其他的 cudaDevice 导致的，加了setCurrentDeive之后导致会出现 hang，不会直接报错了。
  • sanitizer 排查内存问题，
    • sanitizer 跨机给出的 error 分别有：cudaErrorNoKernelImageForDevice (error 209) on cudaGetLastError， CUDA_ERROR_NOT_PERMITTED (error 800) on cuMemCreate，CUDA_ERROR_NOT_SUPPORTED (error 801) on cuMemGetHandleForAddressRange. 三类错误分别是没指定sm90，VMM 不知道为什么分配被拒，不支持ncclCommWindowRegister。❌
    • 发现flagcxOneSideBuildFullMesh内存在下面问题，需要结合 flagcx.cc内flagcxOneSideBuildFullMesh的 for 循环代码来看:

      时间轴 ──────────────────────────────────────────────────────►
    
      rank0:  [i=0: self↔self] ──完成──► [i=1: while循环开始]
                                           └─ connect(rank1.listen)   TCP 进入 rank1 的 accept queue
                                              accept(rank0.listen)    等待 rank1 来连
    
      rank1:  [i=0: while循环]
               connect(rank1.self)   TCP 进入 rank1 自己的 accept queue
               accept(rank1.listen)  ← rank1的accept queue里现在有2个连接:
                                          [A] rank1 自己(self-connect, i=0预期)
                                          [B] rank0 发来的 (i=1来的, 不该这轮消费)
    
      OS 的 accept queue 是 FIFO，但 [A] 和 [B] 谁先到是竞态。如果 rank0 的 TCP connect 先到：
    
      rank1 的 accept() 拿到了 [B] (rank0 的 i=1 连接)
        → recvComm 设置为来自 rank0 的连接 ✓ (recvComm != NULL)
        → while 条件: sendComm==NULL || recvComm==NULL
                     →  recvComm 非 NULL，accept() 不再被调用
    
      rank1 的 connect(self) 还卡在 StateSend/StateConnecting
        → 需要有人 accept() 自己发过去的 QP info
        → 但 while 循环里 recvComm 已非 NULL，不会再调 accept()
        → sendComm 永远是 NULL
        → while(sendComm==NULL || recvComm==NULL) 永远成立
        → rank1 无限循环，sendComm 卡死 ← HANG
    

    问题是，这里在和 MC 讨论中发现 mpich 启动的测试从来不会出现问题，我用 openmpi 会出现问题。就算这里加上 barrier，在 pd 分离的时候依旧会出现 decode 出一样的报错。❌
  • 两边 signal 计数会乱，改成发端统计好有多少signal，通知收端，收端直接只下一次 wait 操作。 ⬇️
  • 在flagcxHeteroWaitSignal内加了D2H的拷贝，把当前收端 current signal 打印出来和 sender 发过来的signal 做对比， 观察到每次连续 runtest的时候第二次测试 recv 端需要 194 个，但是每次卡在 180个左右就再也等不到了，prefill 侧 log 看到 ibrc 打印FLAGCX WARN NET/IB : unable to allocate requests和FLAGCX WARN flagcxRmaProgressThread: op failed peer=1 type=1 res=3 当rma 的 proxyThread 执行的时候，flagcxRmaProgressThread 去调用 ibrc_adaptoe封装的flagcxIbIputSignal，这里当并发大的时候就会返回 flagcxInternalError，然后 flagcxRmaProgressThread 检查不是 flagcxSuccess 就会直接 free 这个 wr。。。。。

      flagcxRmaProgressThread    ← 从 pending 取出 desc
          └─ netAdaptor->iputSignal()   ← IB adaptor 层
              └─ flagcxIbGetRequest()   ← 从 reqs[256] 里找一个 UNUSED slot
                  ← 找到 → 设 type=IPUT, 返回指针存到 desc->request
                  ← 找不到 → "unable to allocate requests", 返回 flagcxInternalError
          └─ 成功后: desc 挂到 inProgress 链表
          └─ 后续循环: netAdaptor->test(desc->request)
              └─ flagcxIbTest → flagcxIbCommonTestDataQp
                  └─ ibv_poll_cq() 收割 CQE
                  └─ events 减到 0 → flagcxIbFreeRequest(r)  ← r->type = UNUSED, slot 回收
              └─ done=1 → rmaDescComplete(desc) → free(desc)
    

    所以问题就是如果256 个 slots 都不是空的时刻，新进来的请求就会被 flagcxIbGetRequest 函数内的for loop 挡在外面，返回的是flagcxInternalError 导致后续的代码直接 free 掉了当前的 desc，因此在这里尝试了不 free，不成功就把当前的 desc 重新enque 到 proxy 链表后，所有

  if (res != flagcxSuccess) { WARN(“flagcxRmaProgressThread: op failed peer=%d type=%d res=%d”, p, (int)desc→type, (int)res); __atomic_store_n(&proxy→rmaError, 1, __ATOMIC_RELEASE); free(desc); ```

• 【bug2】tp=2 的 prefill / decode观察到，出现 hang 的时候每一边都另一个 host:ip 服务看不到

  Prefill：flagcx_connector.py:554: Pair comm ready (responder/rank=1) ↔ 10.8.2.169:8999
  Decode：flagcx_connector.py:575: Pair comm ready (initiator/rank=0) ↔ tcp://10.8.2.168:8999

  Prefill:
  (Worker_TP0 pid=167763) [2026-04-15 19:59:53] INFO flagcx_connector.py:510: Registered 96 KV MRs + per-pair signal buffer for pair comm=0x7fb1d4001160 (signal_ptr=0x7fc0315eb400, signal_device=cuda:0, current_device=0)
  (Worker_TP0 pid=167763) [2026-04-15 19:59:53] INFO flagcx_connector.py:554: Pair comm ready (responder/rank=1) ↔ 10.8.2.169:8998
  (Worker_TP1 pid=167764) [2026-04-15 19:59:53] INFO flagcx_connector.py:510: Registered 96 KV MRs + per-pair signal buffer for pair comm=0x7f8c88001160 (signal_ptr=0x7f8c60200000, signal_device=cuda:0, current_device=0)
  (Worker_TP1 pid=167764) [2026-04-15 19:59:53] INFO flagcx_connector.py:554: Pair comm ready (responder/rank=1) ↔ 10.8.2.169:8999
   
  Decode:
  INFO flagcx_connector.py:510: Registered 96 KV MRs + per-pair signal buffer for pair comm=0x7fb4e4000ba0 (signal_ptr=0x7fc3515eb000, signal_device=cuda:0, current_device=0)
  (Worker_TP0 pid=54913) [2026-04-15 19:59:53] INFO flagcx_connector.py:575: Pair comm ready (initiator/rank=0) ↔ tcp://10.8.2.168:8998
  (Worker_TP1 pid=54914) [2026-04-15 19:59:53] INFO flagcx_connector.py:510: Registered 96 KV MRs + per-pair signal buffer for pair comm=0x7f48f8000ba0 (signal_ptr=0x7f48d6200000, signal_device=cuda:0, current_device=0)
  (Worker_TP1 pid=54914) [2026-04-15 19:59:53] INFO flagcx_connector.py:575: Pair comm ready (initiator/rank=0) ↔ tcp://10.8.2.168:8999

  这里的改动思想很简单，就是 sender 的 work 第一次进来去告诉receiver 我的uid，同时 decode 的 listen 线程提前开始等待这个，一起开始调用commInitRank和_register_kv_for_comm。解决这个 bug2 后在后续测试 bug1 的几十次 vllm serve 都没有出现开头就 hang 的问题了。✅

🚀 今日TODO

• 修复 flagcx connector 两个 bug ✅ 2026-04-17
  • bug1: 加错误码发现收端就是Unhandled device error出错⇒加了set current_device解除这个问题后发现高并发依旧会 hang⇒ sanitizer 扫了一遍内存泄露的所有问题都和这个 hang 无关⇒怀疑 fullmesh 的时候connect 和 accept 会在并发的时候竞争产生 hang，但是和 MC 倒腾一下午发现这个只是 openmpi 的问题⇒后续在 waitSignal 和 prefill 侧增加打印发现是发段请求的 signal 数量和收端对不上⇒确定为 sender 请求丢失⇒读完 proxy 处理 rma 操作的源码，确定为没处理完请求队列槽只有 256，如果256 个 slots 都不是空的时刻，新进来的请求就会被 flagcxIbGetRequest 函数内的for loop 挡在外面，返回的是flagcxInternalError 导致后续的代码直接 free 掉了当前的 desc ⇒把当前的 desc 重新enque 到 proxy 链表后，问题解决 ✅ 2026-04-17
  • bug2：tp=2 的 prefill / decode观察到，出现 hang 的时候每一边都另一个 host:ip 服务看不到。改动思想很简单，就是 sender 的 work 第一次进来去告诉receiver 我的uid，同时 decode 的 listen 线程提前开始等待这个，一起开始调用commInitRank和_register_kv_for_comm。解决这个 bug2 后在后续测试 bug1 的几十次 vllm serve 都没有出现开头就 hang 的问题了。 ✅ 2026-04-20

2026-04-15（周三） Daily

🧠 今天记录

• debug flagcx connector

• 看到flagcxWaitSignal 报错raise RuntimeError(f”FLAGCX error: {error_str}”)
  • 确定了 error 码是 1，就是Unhandled device error ⬇️
  • 先增加了 comm 初始化 并发的隔离，未解决，但是代码保留 ⬇️
  • 然后怀疑是 context 用了其他的 cudaDevice 导致的，加了setCurrentDeive之后导致会出现 hang，不会直接报错。问题不在这，因为打印发现 worker 线程都是这样用的，并且和 mooncake 使用的方式是对齐的，问题不在这。❌
  • sanitizer 排查内存问题，
    • sanitizer 跨机给出的 error 分别有：cudaErrorNoKernelImageForDevice (error 209) on cudaGetLastError， CUDA_ERROR_NOT_PERMITTED (error 800) on cuMemCreate，CUDA_ERROR_NOT_SUPPORTED (error 801) on cuMemGetHandleForAddressRange. 三类错误分别是没指定sm90，VMM 不知道为什么分配被拒，不支持ncclCommWindowRegister。signal 难道分配的有问题？
    • 发现flagcxOneSideBuildFullMesh内存在下面问题，需要结合 flagcx.cc内flagcxOneSideBuildFullMesh的 for 循环来看:

      时间轴 ──────────────────────────────────────────────────────►
    
      rank0:  [i=0: self↔self] ──完成──► [i=1: while循环开始]
                                           └─ connect(rank1.listen)   TCP 进入 rank1 的 accept queue
                                              accept(rank0.listen)    等待 rank1 来连
    
      rank1:  [i=0: while循环]
               connect(rank1.self)   TCP 进入 rank1 自己的 accept queue
               accept(rank1.listen)  ← rank1的accept queue里现在有2个连接:
                                          [A] rank1 自己(self-connect, i=0预期)
                                          [B] rank0 发来的 (i=1来的, 不该这轮消费)
    
      OS 的 accept queue 是 FIFO，但 [A] 和 [B] 谁先到是竞态。如果 rank0 的 TCP connect 先到：
    
      rank1 的 accept() 拿到了 [B] (rank0 的 i=1 连接)
        → recvComm 设置为来自 rank0 的连接 ✓ (recvComm != NULL)
        → while 条件: sendComm==NULL || recvComm==NULL
                     →  recvComm 非 NULL，accept() 不再被调用
    
      rank1 的 connect(self) 还卡在 StateSend/StateConnecting
        → 需要有人 accept() 自己发过去的 QP info
        → 但 while 循环里 recvComm 已非 NULL，不会再调 accept()
        → sendComm 永远是 NULL
        → while(sendComm==NULL || recvComm==NULL) 永远成立
        → rank1 无限循环，sendComm 卡死 ← HANG
    

    问题是，这里在和 mc 讨论中发现 mpich 启动的测试从来不会出现问题，我用 openmpi 会出现问题。就算这里加上 barrier，在 pd 分离的时候依旧会出现 decode 出一样的报错。

🚀 今日TODO

• [ ]

2026-04-14（周二） Daily

🧠 今天记录

• debug flagcx connector

• 看到flagcxWaitSignal 报错raise RuntimeError(f”FLAGCX error: {error_str}”)。
  • 确定了 error 码是 1，就是Unhandled device error
  • 先增加了 comm 初始化 并发的隔离
  • 然后怀疑是 context 用了其他的 cudaDevice 导致的，加了之后导致会出现 hang，不会直接报错。

🚀 今日TODO

• [ ]

2026-04-13（周一） Daily

🧠 今天记录

• 跟MC 对话确定 pr446 的内容 ✅ 2026-04-13
• 弄了会儿 cc switch，配置 openRouter ✅ 2026-04-13
• 给 MC 写使用文档 ✅ 2026-04-13
• 给梦豪更新代码 ✅ 2026-04-13
• debug flagcx connector

🚀 今日TODO

2026-04-10（周五） Daily

🧠 今天记录

• flagcx 需要 git pull 之后完成 stash pop 然后验证当前 pr 没问题 ✅ 2026-04-10
• [ ]

🚀 今日TODO

• 基础 flagcx connector 调通 PD 起服务正常 ✅ 2026-04-13

2026-04-09（周四） Daily

🧠 今天记录

• 确定一下 send_worker 和 收端的 star_load_kv 的时候两侧如何合理下 flagcxCommInitRank ✅ 2026-04-09

🚀 今日TODO

• flagcx connector实现开发； 5. flagcx connector design&&dev&&test ✅ 2026-04-09

2026-04-08（周三） Daily

🧠 今天记录

• kv cache 传输的时候在不同 tp/dp/ep 的 case 下，comm 是怎么建立的？ep下是哪些 rank 之间传输 kv cache ✅ 2026-04-08

🚀 今日TODO

• 修复 flagcxOneSideRegister 的 bug，提 PR ✅ 2026-04-08

2026-04-07（周二） Daily

🧠 今天记录

• 补充开发 flagcx的注册可以拿到 Mr 的索引映射？ ✅ 2026-04-08 在 NCCL/FlagCX 的 IB 层都不需要 comm 隔离注册 MR

• PD是全局的，每个 IB 物理设备只分配一个 PD，所有 comm 的 QP 都在同一个 PD 上创建
• MR 自动跨 comm 复用：IB adaptor 有全局 MR 缓存（flagcxIbDevs[].mrCache），同一物理地址的第二次注册会直接引用计数 +1、返回已有 MR，不会重复调用 ibv_reg_mr
• MR 绑定到 PD 而非 QP，同一 PD 下的任何 QP 都能使用该 MR

🚀 今日TODO

• 修复 flagcxOneSideRegister 的 bug，提 PR ✅ 2026-04-08

2026-04-03（周五） Daily

🧠 今天记录

• 要补充开发 flagcx的注册可以拿到 Mr 的索引映射
• 整体代码结构重构完成 ✅ 2026-04-03

🚀 今日TODO

• 修复 flagcxOneSideRegister 的 bug，提 PR ✅ 2026-04-08
• flagcx connector实现，放在vllm-plugin-fl；Nccl engine→flagcx engine，和mooncake性能对齐； 5. flagcx connector design&&dev&&test

2026-04-02（周四） Daily

🧠 今天记录

• 确定 batch_transfer_sync_write 的完整逻辑，mooncake 先找多个request内的连续地址 重分配出来 mooncake 格式的 task，再每个 task 切成更小的 slice 给 ibv_post_send，同理再 ibv_poll_cq所有 slice，都是complete 状态后结束。 ✅ 2026-04-03
• 机内 mooncake 传输逻辑？
• mooncake实例化engine 和 engine initialize怎么做的？是实例化一个TransferEngineImpl 实例 ✅ 2026-04-03
• get_rpc_port 应该怎么做？返回的是 RPC 服务的 TCP 端口，这是每个 engine 用来传输网卡注册后的 MR 索引，rkey 的 ✅ 2026-04-02
• 怎么 batch 粒度的去 register？还需要确定使用 flagcx 现在的一堆接口中单边还是双边的 register？这里是一下注册一大块 kv cache，在通过 RPC 去交换 NIC 需要的 metadata。flagcx 内单边把自己这一块大的给注册了。✅ 2026-04-02
• 补充开发 flagcx的注册可以拿到 Mr 的索引映射

🚀 今日TODO

• 完成 mooncake 传输流程梳理（task 重组与 slice 发送/完成机制），理清 engine 初始化路径及 RPC 端口在 MR 索引与 rkey 交换中的作用；同时确定 flagcx 当前采用单边大块内存注册并通过 RPC 交换元数据的实现方案。