Micha Nelissen mi...@neli.hopto.org 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
Bounine, Alexandre wrote:
Micha Nelissen mi...@neli.hopto.org 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
Micha Nelissen mi...@neli.hopto.org 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.
Micha Nelissen mi...@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
Bounine, Alexandre wrote:
Micha Nelissen mi...@neli.hopto.org 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.
Micha Nelissen mi...@neli.hopto.org 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
Bounine, Alexandre wrote:
Micha Nelissen mi...@neli.hopto.org 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
Micha Nelissen mi...@neli.hopto.org 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
Bounine, Alexandre wrote:
Micha Nelissen mi...@neli.hopto.org 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
Micha Nelissen mi...@neli.hopto.org 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
Bounine, Alexandre wrote:
Micha Nelissen mi...@neli.hopto.org 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
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
12 matches
Mail list logo
