Re: [PATCH for-next V1 25/29] net/mlx4_core: Adjustments to SET_PORT for SRIOV-IB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 6, 2012 at 6:09 AM, Roland Dreier <roland@xxxxxxxxxx> wrote:
>>> So I can't run a SM in a guest?
[...]
>>> I can't run an SRP target in a guest?

> Seems like an unfortunate set of limitations, especially if I want a
> completely virtualized environment.  In my case I might want to
> test the same OS image that I deploy on physical HW inside a VM,
> and both running an SM and having a storage target seem like things
> I would want to do. Is it planned to fix this with more complete paravirtualization?

Re SM - in the SRIOV implementation for ConnectX, VFs are identified
by their GUIDs. Consequently, in the general case, any request or
unsolicited MAD must have a GRH.
However, the SM cannot be reached by MADs with GRH by remote nodes
because the IBTA PortInfo only provides the SM LID - the SM GID cannot
be discovered. Additionally, the Trap messages sent by many existing
IB elements do not comprise a GRH.
As a result, the SM can only be run on a function that is specifically
designated for default (GRH-less) forwarding of SMPs. Currently, this
is the PF, but a specific VF could be selected just the same in the
future. Note that SMP access should be restricted to designated &&
*trusted* VFs, as SMPs are agnostic to partitioning and allow nodes to
take over ports before the SM. A trust model for VF should be
developed.

Re. device management - currently, SRP targets cannot be discovered in
SRIOV, as the IsDeviceManagementSupported port capability is a
property of the physical port rather than of each VF. To implement
this some standardization should take place.

All in all, it is possible to extend the current impl. such that the
issues you brought arer addressed with more complete
paravirtualization, we will follow on that. Still, I don't see
something in the grounds of the submitted code that contradicts these
extensions, its matter of more work.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux