RE: When IBoE will be merged to upstream?

Liran Liss
2010-07-15T10:55:32Z

> > > The text is saying that the specification does not use any of the
> > > LID fields in the verbs interface, that is it. It isn't talking
> > > about MAC addresses.
> > >
> > > Exactly how and where the MAC address comes about was
> never decided,
> > > and at least some participants thought it should be a 1:1
> > > algorithmic mapping from the GID.
> > >
> > > Ditto for VLANs, how and where the vlan tag comes about
> is not part
> > > of the spec.
>
> > You are trying to rewrite history.
> > Read the spec, address handles fields are fixed.
>
> Not really, this was all discussed on this list before the
> IBxoE working group was formed,

The paragraph above is about the RoCE spec. And *this list* did not write the RoCE spec.

> it was discussed in the
> working group,

The RoCE spec adopts the verbs defined in the base IB spec and does not add any new input modifiers to the AH verb. You may not agree with it but that does not change the spec.

> I objected to the draft spec leaving this area
> absent, even.

You should submit a comment on this matter using the IBTA comment tracker database if you intend your concern to be taken into account.

> The spec doesn't say squat about how MAC and
> VLAN values get into the AH,

True. The spec does not say it because there are no MAC and VLAN input modifiers to the "create AH" verb. The spec assumes the resolution from the L3 address happens below the channel interface.

> and you have already heard how
> my opinion on this subject differs from others.

I never attempted to misrepresent your opinion. I am just pointing out what the RoCE spec says.

>
> > > But, even if we do get there some day then we could extend the AH.
> >
> > This is unacceptable - we are not going to add another L3
> identifier.
>
> It wouldn't be adding another L3 itentifier it would be an L2
> next hop MAC address for the router. It would be nice to do
> this from the start but if growing the AH is really that
> scary then it should wait until someone figures out how to
> solve the lossless routing problem on ethernet.

Augmenting the AH has a significant cost. There is a tradeoff here between preserving the verbs api vs. dealing with the implementation challenges associated with doing address resolution below the verbs. The RoCE spec deliberately chooses one direction. You seem to favor the other one. But in the interest of progress and since we all seem to agree on the way things work when we use link local GIDs, let us move forward with that approach for now. And we can get back to non local GIDs later.