RE: When IBoE will be merged to upstream?

Hefty, Sean
2010-07-02T00:20:05Z

> There are also good reasons why the RoCE standard left the syntax of
> address handles.
> First, it keeps the Verbs unchanged. Even if you are using rdmacm to make
> connections, you still have to inspect address handles when "connecting" to
> UD QPs or joining multicast addresses.

Verbs isn't an API, and the verbs usage changed anyway - the L2 is no longer provided by the user. The spec is wrong to make the L3 to L2 mapping device specific, if that was the intent. ARP or neighbor discovery should not be hidden under create AH or modify QP.

> Second, making Ethernet L2 fields explicit has implications beyond the
> address handle and CQE formats. Specifically, a lot of the IBTA defined
> MADs must be modified as well.

Specifically, which MADs and why?

> The most evident example is the CM protocol, which has L2 fields in its
> payloads.

How does moving the L3 to L2 mapping from outside create AH result in the CM protocol needing to change? Why is hiding this under modify QP desirable?

> Third, RoCE is not IB; its all about making RDMA user-friendly to Ethernet
> users.

Then why is it part of the IBTA?

> Most importantly, we don't want to change the way Ethernet networks are
> managed.
> This means that admins configure their normal network interfaces, define
> VLAN sub-interfaces, assign IP addresses (or use DHCP), and then work with
> RoCE using IP-mapped addresses, which reference the same IP addresses they
> use for their Ethernet interfaces.
> So, regarding our VLAN discussion:
> - RoCE gids are L3 addresses, which are not (necessarily) of link-local
> scope; people will mostly use IP-mapped gids of global scope.
> - These gids will map to an IP address, which then can resolve to an
> outgoing vlan device exactly as in Ethernet.
>
> We have a specification, we have an implementation, and we have clean way
> of passing RoCE L2 information to user-space via address handles.
> I don't see any substantial reason to change the basic approach.

All feedback on this has been discarded since the initial patches were submitted, and I still don't see a substantial reason why L3 to L2 mappings are device specific, or why significant network protocols should be hidden under verbs calls.