On 13/09/2012 18:53, Or Gerlitz wrote:
The physical PKey table can contain both full and partial memberships
of the same Pkey.
This is needed to serve 2 VFs that are granted access to the same
PKey, albeit with different membership types.
Example use case -- RDMA or IPoIB network storage (fil
On 11/09/2012 19:52, Doug Ledford wrote:
On 8/3/2012 4:40 AM, Jack Morgenstein wrote:
>Enhance the cached and non-cached pkey table lookups to enable limited and full
>members of the same pkey to co-exist in the pkey table.
>
>This is necessary for SRIOV to allow for a scheme where some guests w
On 13/09/2012 10:35, Jack Morgenstein wrote:
I seem to recall that there were problems with IPoIB when partial membership
pkeys are used.
There are some issues in the overall solution, since ARPs sent over the
broadcast group reach
also nodes with partial membership their HCA generated pkey v
On 13/09/2012 10:35, Jack Morgenstein wrote:
I seem to recall that there were problems with IPoIB when partial membership
pkeys are used.
There are some issues in the overall solution, since ARPs sent over the
broadcast group reach
also nodes with partial membership their HCA generated pkey v
On Wednesday 12 September 2012 19:48, Doug Ledford wrote:
> > On the Hypervisor, however, we assume that if both versions of the pkey are
> > in its pkey table,
> > then for its own infiniband operation (as opposed to performing its pkey
> > virtualizing function),
> > it should operate with the
On 09/12/2012 03:56 AM, Jack Morgenstein wrote:
> On the Hypervisor, however, we assume that if both versions of the pkey are
> in its pkey table,
> then for its own infiniband operation (as opposed to performing its pkey
> virtualizing function),
> it should operate with the highest membership t
On Tuesday 11 September 2012 19:52, Doug Ledford wrote:
> On 8/3/2012 4:40 AM, Jack Morgenstein wrote:
> > Enhance the cached and non-cached pkey table lookups to enable limited and
> > full
> > members of the same pkey to co-exist in the pkey table.
> >
> > This is necessary for SRIOV to allow f
On 8/3/2012 4:40 AM, Jack Morgenstein wrote:
> Enhance the cached and non-cached pkey table lookups to enable limited and
> full
> members of the same pkey to co-exist in the pkey table.
>
> This is necessary for SRIOV to allow for a scheme where some guests would
> have the full
> membership pk
Enhance the cached and non-cached pkey table lookups to enable limited and full
members of the same pkey to co-exist in the pkey table.
This is necessary for SRIOV to allow for a scheme where some guests would have
the full
membership pkey in their virtual pkey table, where other guests on the sa
