Micha Nelissen wrote:
>
> In various parts of the enumeration and routing algorithm, it would
need
> to lookup the tag to find the destid, if the destid is in the tag then
> this lookup is not needed.
Let's keep this discussion within limits of the current implementation.
Existing method of form
Bounine, Alexandre wrote:
Micha Nelissen wrote:
I look at it this way: it prevents the need for another layer of
indirection: translating component tag to a destid.
The destid alone is not enough. You will need an entire rio_dev object
for that device anyway.
?? I did not say a rio_dev obje
Micha Nelissen wrote:
>
> I look at it this way: it prevents the need for another layer of
> indirection: translating component tag to a destid.
The destid alone is not enough. You will need an entire rio_dev object
for that device anyway.
>
> Why no relation? My experience is that during debu
Bounine, Alexandre wrote:
Micha Nelissen wrote:
that switch. The tag uses one extra bit to identify the device as a
switch instead of an endpoint. This provides the information to
unambiguously identify a switch from an endpoint.
OK taking away #2. But do not see how it justifies storing two
Micha Nelissen wrote:
>
> Bounine, Alexandre wrote:
> > 1. The destid for the switch needs an additional mechanism to share
it
> > among processors in the RIO network,
>
> ? See comment for 2)
>
> > 2. It takes ID value away from the pool of available IDs, what will
>
> It does not take an ID
Bounine, Alexandre wrote:
Micha Nelissen wrote:
rid of rswitch->switchid and use component_tag directly for
switches).
I still prefer the destid as the single identification id.
In your patch you allocate individual destid for switches. This method
has two problems:
1. The destid for the sw
Micha Nelissen 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
Bounine, Alexandre wrote:
Micha Nelissen wrote:
rswitch->rdev->destid should be the id associated with a given switch,
so that every (processor) device can agree what id some switch has.
If we will need to identify the same physical switch by different
processors we may use the component tag
Micha Nelissen wrote:
>
> Bounine, Alexandre wrote:
> > Looks like I formulated it bad - better would be: they have
different
> > interpretation by hardware but logically in RapidIO they have single
> > role - destid/hopcount are a device coordinates in the RIO network
used
> > to access that dev
Bounine, Alexandre wrote:
Micha Nelissen wrote:
Alexandre Bounine wrote:
How can you say this? The two variables have different meanings, this
logically implies you can't merge them. So how do you say 'this does
not
prevent us from ...' without providing a reason?
Looks like I formulated it
Micha Nelissen wrote:
>
> Alexandre Bounine wrote:
> > 1. Using one storage location common for switches and endpoints
eliminates
> > unnecessary device type checks during maintenance access operations.
> > While destination IDs and hop counts have different meaning for
endpoints and
> > switches
Alexandre Bounine wrote:
1. Using one storage location common for switches and endpoints eliminates
unnecessary device type checks during maintenance access operations.
While destination IDs and hop counts have different meaning for endpoints and
switches, this does not prevent us from storing th
12 matches
Mail list logo
