Hi Micha, Sorry for delayed reply.
Micha Nelissen <mi...@neli.hopto.org> wrote: > > Bounine, Alexandre wrote: > > struct rio_dev { > > struct list_head global_list; > > struct list_head net_list; > > ..... > > ..... rest of rio_dev > > ..... > > struct rio_switch switch[0]; > > } > > It makes sense to let rio_dev structures point to the switch they are > attached to. That can be useful in various situations, but is not > possible with this setup. > > If a rio_dev is a switch then rdev->rswitch->rdev == rdev holds. > But the switch is a RIO device itself and all other parts of rio_dev structure are applicable to it as well. If there is situation when a device needs to hold a pointer to the attached switch that should be a pointer to the switch rio_dev and not to its switch-specific extension. > > This will remove extra memory allocation, remove overlapping structure > > members and clean code sections like one shown below: > > > > u8 hopcount = 0xff; > > u16 destid = rdev->destid; > > > > if (rdev->rswitch) { > > destid = rdev->rswitch->destid; > > hopcount = rdev->rswitch->hopcount; > > } > > Note that it is possible for rdev->destid to differ from > rdev->rswitch->destid even if rswitch->rdev == rdev (for non-hosts i.e. > agents). rswitch->destid is the destid by which we discovered the switch > (and can reach it) but rdev->destid is the actual id given to the switch. > My goal is to have one destid storage for device - endpoint or switch. And destid should be used only for one purpose: to reach corresponding device. In your statement above you suggest using rdev->destid instead of rswitch->switchid. RIO switches do not have any specific RIO ID that can be assigned to the switch. In this case the rswitch->switchid should work well for logical identification of the switch. I think if (for switch) we load rdev->destid with some function different from its routing role this may bring unnecessary confusion. I also will move rswitch->hopcount to rdev->hopcount. For endpoint it will be set to 0xff during rio_dev initialization. Alex. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev