On Mon, Apr 08, 2019 at 11:49:04AM +0200, Lukas Wunner wrote: > On Mon, Apr 08, 2019 at 12:07:44PM +0300, Mika Westerberg wrote: > > On Mon, Apr 08, 2019 at 10:53:37AM +0200, Lukas Wunner wrote: > > > Hm, what other cases are there, i.e. what is the meaning of a > > > tb_regs_hop's > > > "next_hop" field if "out_port" doesn't have a remote? (And why does it > > > need to be tracked on the out_port? In case a remote is added later?) > > > > We also need to program HopIDs for adapter ports (PCIe, DP, NHI) in > > order to enable a path. The "next_hop" from NULL port to an adapter port > > tells the HopID a packet gets when it is routed to the adapter port and > > the adapter port registers then are used to specify which HopID means > > what (for PCIe there is only 8 but for DP there is 8 and 9, for NHI it > > can be anything the service driver has negotiated). > > Okay, so in_hopids are the entries allocated in this port's hop config > space, whereas out_hopids only really bears significance for adapter > ports. For null ports (in-between two adapter ports on a path), > out_hopids is identical to the in_hopids of the next hop (IIUC). > > That probably merits mentioning in struct tb_port's kerneldoc.
Sure, will do.
