[PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches

[Bounine, Alexandre]

Micha Nelissen <micha at neli.hopto.org> wrote:
> Bounine, Alexandre wrote:
> > If we will need to identify the same physical switch by different
> > processors we may use the component tag which now is unique for
every
> > device.
> 
> Yes, identification is the point. I think it might be confusing to
have
> a destid *and* a component tag id which are slightly different. The
> destid is unambiguous (if you know whether the device is a switch or
> endpoint) so I think it makes sense to use that if possible.

The component tag is the way to identify a RIO device (switch or
endpoint).
1. it is defined by RIO spec as a register existing in both types of
devices (this provides a universal access to the identification
information by any processor).
2. the Error Management specification already uses the CT as a device
identifier.
3. the CT value is large enough to be unique for max number of endpoints
in the large system and any reasonable number of switches. BTW, I am
planning to provide a patch that defines CT fields to ensure future
compatibility.

The destid does not exists as a HW element of switches and therefore
cannot be used as a universal identification token.

> > This actually gives me another idea: instead of using global
> > next_switchid counter make rswitch->switchid = component_tag and
> > switches in sysfs will look identical for every processor (or just
get
> > rid of rswitch->switchid and use component_tag directly for
switches).
> 
> I still prefer the destid as the single identification id.

As I answered above, destid cannot be used as a universal identification
token - it is a routing element. The destID has register in endpoints
only to provide a packet filtering.

In your patch you allocate individual destid for switches. This method
has two problems:
1. The destid for the switch needs an additional mechanism to share it
among processors in the RIO network,
2. It takes ID value away from the pool of available IDs, what will
reduce number of IDs that can be assigned to endpoints. (NOTE: I am
actually working on destID assignment scheme that will recycle destID in
case of hot-swap events, i.e. if device is extracted its destID will be
returned to the pool of available IDs and may be reused later for device
insertion).

The only case when assigning individual destid to the switch is
justified is an "empty" switch - one without any endpoints attached to
it. But that destid should be assigned to an endpoint as soon as it is
attached to that switch.  

Alex.