0821： 1.Status参考tf的玩法 2.AllocationResult改叫 StreamPlan 3.DAGGraph接口参数类型考虑ABI兼容性 4.DAGNode开出来 Graph和Node分开 （甚至Graph是否可以去掉） 6.GE Pass是不是也可以走python 接口 7.StreamPassContext有没有开放python接口 --还没开 8.探索minidag全量替换成python 930完成 9.aclgraph开了c接口给torch 参考实现 10.结果中的has_profiling_match有必要加吗 11.DAG图可能不需要区分控制边和数据边，直接叫AddEdge 按原来的方法 12.SetNodeTopoId接口不用开 13.SetSerialFlag保留 SetCost(应该只保留串行标记就行了，profiling解析放内部) 14.class PassStage要补下流分配阶段
0827： 1.register_stream_pass改成泛化的名字，如register_resource_plan_pass，注册时可以适配不同的name、pass stage、descriptor kind等等,目的是未来可以通过该装饰器注册其他资源优化类pass 2.去掉DeviceResource，目前算法通过profiling读取核数，当前DeviceResource传的核数实际没有用到，未来也不会再用了 3.StreamPass的入参用ge.graph.Graph，不要用StreamGraphView，一是增加用户学习成本，二是不利于后面的扩展，通过文档和注释提示StreamPass内不要改图，另外我们所跑的图节点数量目前只是百级别的，不必为了一点性能收益过度优化 4.在minidag公开api层开放NodeCost，收编execution_time、cube、vector core cnt等，DAGNode开放SetNodeCost接口，方便未来用户传入节点执行耗时的详细消息，便于做更精细化编排。 此外，考虑一下NodeCost的扩展性 5.DAGNode的set_serial_flag方法是用来传递节点上的_stream_label属性的，但是方法名的语义不易懂，换个更好合适的名字
0821：
1.Status参考tf的玩法
2.AllocationResult改叫 StreamPlan
3.DAGGraph接口参数类型考虑ABI兼容性
4.DAGNode开出来 Graph和Node分开 （甚至Graph是否可以去掉）
6.GE Pass是不是也可以走python 接口
7.StreamPassContext有没有开放python接口 --还没开
8.探索minidag全量替换成python 930完成
9.aclgraph开了c接口给torch 参考实现
10.结果中的has_profiling_match有必要加吗
11.DAG图可能不需要区分控制边和数据边，直接叫AddEdge 按原来的方法
12.SetNodeTopoId接口不用开
13.SetSerialFlag保留 SetCost(应该只保留串行标记就行了，profiling解析放内部)
14.class PassStage要补下流分配阶段
0827：
1.register_stream_pass改成泛化的名字，如register_resource_plan_pass，注册时可以适配不同的name、pass stage、descriptor kind等等,目的是未来可以通过该装饰器注册其他资源优化类pass
2.去掉DeviceResource，目前算法通过profiling读取核数，当前DeviceResource传的核数实际没有用到，未来也不会再用了
3.StreamPass的入参用ge.graph.Graph，不要用StreamGraphView，一是增加用户学习成本，二是不利于后面的扩展，通过文档和注释提示StreamPass内不要改图，另外我们所跑的图节点数量目前只是百级别的，不必为了一点性能收益过度优化
4.在minidag公开api层开放NodeCost，收编execution_time、cube、vector core cnt等，DAGNode开放SetNodeCost接口，方便未来用户传入节点执行耗时的详细消息，便于做更精细化编排。
此外，考虑一下NodeCost的扩展性
5.DAGNode的set_serial_flag方法是用来传递节点上的_stream_label属性的，但是方法名的语义不易懂，换个更好合适的名字