On Sun, Mar 29, 2015 at 4:51 PM, Or Gerlitz <[email protected]> wrote: > Under the existing implementation for virtual GIDs, if the SM is not > reachable or incurs a delayed response, or if the VF is probed into a > VM before their GUID is registered with the SM, there exists a window > in time in which the VF sees an incorrect GID, i.e., not the GID that > was intended by the admin. This results in exposing a temporal identity > to the VF.
Hi Roland, so your for-next branch is again way behind, still on 3.19 and while 4.0 is soon @ rc6, we couldn't even rebase this series on it. It's really hard where your tree is really active once every nine weeks or so, e.g only few days before/after rc1's. I'm not sure what you expect us to do, kernel development simply needs not be like this. April 3rd-12th is holiday here, and we would like to really really know early this week what you intend to pull for 4.1 out of the pending things in linux-rdma. Or. > Moreover, a subsequent change in the alias GID causes a spec-incompliant > change to the VF identity. Some guest operating systems, such as Windows, > cannot tolerate such changes. > > This series solves above problem by exposing the admin desired value instead > of the value that was approved by the SM. As long as the SM doesn't approve > the GID, the VF would see its link as down. > > In addition, we request GIDs from the SM on demand, i.e., when a VF actually > needs them, and release them when the GIDs are no longer in use. In cloud > environments, this is useful for GID migrations, in which a GID is assigned to > a VF on the destination HCA, while the VF on the source HCA is shut down (but > the GID was not administratively released). > > For reasons of compatibility, an explicit admin request to set/change a GUID > entry is done immediately, regardless of whether the VF is active or not. This > allows administrators to change the GUID without the need to unbind/bind the > VF. > > In addition, the existing implementation doesn't support a persistency > mechanism to retry a GUID request when the SM has rejected it for any reason. > The PF driver shall keep trying to acquire the specified GUID indefinitely by > utilizing an exponential back off scheme, this should be managed per GUID and > be aligned with other incoming admin requests. > > This ability needed especially for the on-demand GUID feature. In this case, > we > must manage the GUID's status per entry and handle cases that some entries are > temporarily rejected. > > The first patch adds the persistency support and is pre-requisites for the > series. Further patches make the change to use the admin VF behavior as > described above. > > Finally, the default mode is changed to be HOST assigned instead of SM > assigned. This is the expected operational mode, because it doesn't depend on > SM availability as described above. > > Yishai and Or. > > Yishai Hadas (9): > IB/mlx4: Alias GUID adding persistency support > net/mlx4_core: Manage alias GUID per VF > net/mlx4_core: Set initial admin GUIDs for VFs > IB/mlx4: Manage admin alias GUID upon admin request > IB/mlx4: Change init flow to request alias GUIDs for active VFs > IB/mlx4: Request alias GUID on demand > net/mlx4_core: Raise slave shutdown event upon FLR > net/mlx4_core: Return the admin alias GUID upon host view request > IB/mlx4: Change alias guids default to be host assigned > > drivers/infiniband/hw/mlx4/alias_GUID.c | 468 > +++++++++++++++++++++-------- > drivers/infiniband/hw/mlx4/main.c | 26 ++- > drivers/infiniband/hw/mlx4/mlx4_ib.h | 14 +- > drivers/infiniband/hw/mlx4/sysfs.c | 44 +-- > drivers/net/ethernet/mellanox/mlx4/cmd.c | 42 ++- > drivers/net/ethernet/mellanox/mlx4/eq.c | 2 + > drivers/net/ethernet/mellanox/mlx4/main.c | 39 +++ > drivers/net/ethernet/mellanox/mlx4/mlx4.h | 1 + > include/linux/mlx4/device.h | 4 + > 9 files changed, 459 insertions(+), 181 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
