Re: [LSF/MM TOPIC] [ATTEND] SR-IOV Management

[chetan loke <loke.chetan@xxxxxxxxx>]

On Wed, Mar 14, 2012 at 2:07 PM, Chad Dupuis <chad.dupuis@xxxxxxxxxx> wrote:
>
>
> On Wed, 1 Feb 2012, Hannes Reinecke wrote:
>
>> On 01/31/2012 08:02 PM, Chad Dupuis wrote:
>>>
>>> With more and more storage controller hardware supporting SR-IOV in
>>> next
>>> couple of years it seems to make sense at this point to discuss, from a
>>> storage stack perspective, managing how we instantiate and manage
>>> SR-IOV
>>> virtual functions (VFs).  Currently for hardware that does support
>>> SR-IOV,
>>> the management of that functionality is managed entirely by the
>>> hardware
>>> device driver.  However, a more dynamic management to how VFs are
>>> created
>>> and destroyed (assuming the hardware supports it) may be more desirable
>>> since the most common use case, assigning VFs to virtual guests, also
>>> tends to be very dynamic and fluid.  We also need to consider how VFs
>>> interact with complimentary technology such as NPIV in Fibre Channel.
>>>
>>> I'd like to propose that we discuss the following issues to see if a
>>> consensus can be reached about how to deal with them:
>>>
>>> * VF instantiation
>>> * VF/NPIV port pairing
>>> * Namespace management
>>> * LUN presentation
>>>
>> Actually, SR-IOV on FC should be easy to handle; it maps quite
>> easily on NPIV (which probably was the intention :-).
>
>
> I would bet it's not a coincidence ;-)  The question I had was do we
> represent this relationship at the transport level, such as the FC
> transport in this case, or do we let the low-leve driver take care of the
> mapping? In other words, do we have a low level driver create the vport when
> it is instantiating a VF or do we add an option to say fc_vport_create so
> that a VF is created along with a vport.

Chad - would we always need a vport-context if just a VF needs to be
mapped to a guest and NPIV is not enabled?


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