Messages in this thread | | | Subject | RE: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches | Date | Mon, 25 Oct 2010 06:22:54 -0700 | From | "Bounine, Alexandre" <> |
| |
Micha Nelissen <micha@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.
| |