[openib-general] IPv6oIB neighbour discover broken when MCGs overflow

[Hal Rosenstock]

On Fri, 2007-02-16 at 13:07, Roland Dreier wrote:
>  > For starters, I think that rate, MTU, and SL (and maybe PKey too) need
>  > to be the same. There may be others too if I stare at the spec for a
>  > while...
> 
> Can you expand on why?  For example I definitely can send to the same
> MLID with different SLs.  

Sure but I think this complicates the SL2VL tables in the subnet to
accomodate this. I think a similar thing is true for PKeys. So to me
this is an SM complexity issue when mapping multiple MGRPs to same MLID.

> Of course MTU and rate need to match up but
> I don't see that as a real restriction -- the SM needs to allows for
> least-common-denominator values anyway, since the least-capable node
> on the fabric might join an existing group.

In theory, the least capable node could join any group but is this
reality in operation ?

Different groups could have different LCDs so this would make things
less granular (one rather than multiple LCDs). This seems less
constraining to me.

> I don't see why one MCG with an MTU of 2048 and one MCG with an MTU of
> 1024 can't share the same MLID, as long as the underlying fabric is
> capable of supporting an MTU of 2048.

>From a pure MTU standpoint, the (only) downside of this is that the
group with MTU 1024 could send larger packets.

> Actually, I wonder what the
> spec says about what switches should do if they're asked to forward
> packets with too-big MTUs?  Maybe it all works out anyway.

They get dropped on the output port as packet length > NeighborMTU.
That's part of what PortXmitDiscards counts.

Bottom line: I'm not sure anything precludes what you are saying (I do
need to look at the spec more in terms of this), but I do think there
are different levels of complexity in SM implementation depending on how
much flexibility in mapping multiple MGRPs to the same MLID is
"desired".

-- Hal

>  - R.