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
