On Sun, Mar 10, 2019 at 05:02:45PM +0000, Parav Pandit wrote: > > > > On Sun, Mar 10, 2019 at 04:45:30PM +0000, Parav Pandit wrote: > > > > > > > > On Sun, Mar 10, 2019 at 04:18:37PM +0000, Parav Pandit wrote: > > > > > > > > > > > > > > > > > From: Leon Romanovsky <leonro@xxxxxxxxxxxx> > > > > > > > > > > > > Reuse existing RDMA_NLDEV_ATTR_LINK_TYPE to give ability for > > > > > > stable names UDEV rule create Ib device stable names based on > > > > > > link type > > > > protocol. > > > > > > The assumption that devices like mlx4 with duality in their link > > > > > > type under one IB device struct won't be allowed in the future. > > > > > > > > > > > I was under impression that it qedr or cavium driver has iwarp and > > > > > roce > > > > ports on same hca. > > > > > Any reason to not have the link type on per port basis? > > > > > > > > Not really, they don't mix link types in one IB device, I remember > > > > that Jason ensured that during code review. > > > > > > > > > If it already exist at port level, than at device level addition is > > confusing. > > > > > It is like having port_num in ah_attr and also in qp_attr. > > > > > > > > It is just a name with already existing index and proper values. > > > > What name do you think more appropriate? I'll add alias for that, > > > > something like "RDMA_NLDEV_ATTR_NEW_COOL_NAME = > > > > RDMA_NLDEV_ATTR_LINK_TYPE" > > > Why can't we keep it as port attribute? > > > > I didn't find any reason to expose it as port attribute, especially after Jason's > > "request" to do "technology" property per-device. > It is at port level in verbs, so it is not harmful to keep it as port level, instead of duplicating it at device level. > I agree. When we went to the "port_imutable" patch set years ago we started a move toward having attributes be port based as much as possible. I'm failing to understand why link type needs to be part of an immutable device instance name? This is where "mlx4_0" worked because it was a "mlx4" device -- device instance number 0. I know that we are moving toward a single driver supporting more device types so having the driver name is probably not the right name but perhaps we should just name the devices. Since we are already cryptic should we use the PCI device ID? But using driver name could still work. Couldn't it? I still think this is going to be hard for users. But eventually I think it will be better once the tools figure out how to "translate" and/or users figure out how to assign names. Ira
