Hi Arun,
Thanks your feedback, Please see my comments inline. 发件人: arunsubash_manic...@dell.com [mailto:arunsubash_manic...@dell.com] 发送时间: 2015年4月27日 15:51 收件人: che...@centecnetworks.com; g...@microsoft.com; opencompute-networking@lists.opencompute.org 主题: RE: [Opencompute-networking] SAI 0.9.2 questions&topics discussion Dell - Internal Use - Confidential Comments inline From: opencompute-networking-boun...@lists.opencompute.org [mailto:opencompute-networking-boun...@lists.opencompute.org] On Behalf Of chenyq Sent: Monday, April 27, 2015 12:35 PM To: g...@microsoft.com; opencompute-networking@lists.opencompute.org Subject: [Opencompute-networking] SAI 0.9.2 questions&topics discussion Hi All, Last week, Center had a conference call with Guohan to discuss SAI 0.9.2 (thanks Guohan). At the meeting, Guohan suggested to send some of the topics to the mailing list for more discussion. Please review the following questions/topics and appreciate feedback. 1, FDB aging. MAC&VLAN lookups are usually required to find out the output port when performing Route Nexthop operation. But if the MAC is aged, some vendor’s action is flooding this L3 packet in VLAN, and some vendor’s action is discarding the packet and copy_to_cpu. Shall we define the nexthop/neighbor action after MAC aged? <Arun> We have these attributes for the same. Once a MAC ages out there will be look up failure and we have attributes to define the action based on the packet types /* Flood control for packets with unknown destination address. * [sai_packet_action_t] (default to SAI_PACKET_ACTION_FORWARD) */ SAI_SWITCH_ATTR_FDB_UNICAST_MISS_ACTION, SAI_SWITCH_ATTR_FDB_BROADCAST_MISS_ACTION, SAI_SWITCH_ATTR_FDB_MULTICAST_MISS_ACTION, We have different actions defined in packet_action_t �C drop, flood, trap to CPU <Yuqiang> Oh, right. I understand your mean. User can define the action as DROP or FLOOD. If it is NP with Neighbor table supported, OK, there are no problem. If it is ASIC without Neighbor table supported, then it is difficult to support L3 packets FLOOD. Maybe it is a issue. 2, PORT Loopback _sai_port_internal_loopback_mode_t is to define “internal loopback mode”. With this mode, the packets will go through ASIC/NPU and return at PHY or MAC module at egress. It would be good to add another “external loopback mode”. With this mode, the packets will return at PHY or MAC module at ingress. Shall we extend the loopback type to support this? 3, PORT auto-negotiation Currently there are no “auto-negotiation” option on PORT, so can we add this attribute to PORT. <Arun> Yes we can add this 4, LAG schedule mode is it possible to add like “RR(Round Robin) and DLB(Dynamic Load balance)”. DLB LAG is an important option in DC application. <Arun> Yes the plan is to enhance Hash as part of V093 and these could be considered as part of that <Yuqiang> Thanks 5, LAG number and LAG member number Is it possible to add “LAG member number” attribute to LAG. It should be Read-only attribute to describe the ASIC/NPU capability. And another LAG capability is the LAG number. <Arun> Can you elaborate more on this -Arun <Yuqiang> LAG number is ASIC/NP capability. For example, some ASIC can support up to 128 LAGs. LAG is a bundle of some physical ports. These physical port are LAG member. ASIC/NP can’t support limitless member, so we ask add this “LAG member number” as LAG capability. For example, some ASIC can support up to 64 members per LAG. 6, MLAG Support. Is it possible to add port-isolate function to SAI. We can support MLAG with this port-isolate function. Another, port-isolate function can be used for security. 7, ACL Entry action Currently SAI defines ACL stage as ingress and egress. And there are many actions which should be supported at all ingress stage and egress stage. it will cause limitations here. So it is a issue that how to clearly describe the specified ASIC/NPU ACL capability. Or can we separate these actions from ingress to egress. 8, NextHop group with multicast-support Currently there are nexthop-group module in SAI 0.9.2. and it only support ECMP group type. We need add another type “MULTICAST group type”With which we can support multicast application. Shall we add that? Any feedback are welcome. Yuqiang thanks Centec Networks (suzhou) Co., Ltd. Web： <http://www.centecnetworks.com> www.centecnetworks.com Room13/16,4F,Building B,No.5Xing Han Street, Suzhou Industrial Park,Jiang Su Province,China
_______________________________________________ opencompute-networking mailing list Unsubscribe: http://lists.opencompute.org/mailman/options/opencompute-networking opencompute-networking@lists.opencompute.org http://lists.opencompute.org/mailman/listinfo/opencompute-networking
