On Wed, 14 Mar 2012, chetan loke wrote:
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?
I don't believe so though you would still need some mechanism for the VF
to address external devices.
Chetan
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
