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

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

[Chad Dupuis]

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

Any other subtopics to add to this discussion are obviously welcomed.

Thanks,
Chad

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.

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

[Hannes Reinecke]

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 :-).

However, for SAS things get really tricky, as we don't have virtual
SAS IDs. Some vendor was actually planning on doing ACLs in firmware
(shudder).

And then there is the pci-stub mess.

So yes, definitely something to discuss here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Chad Dupuis]

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.

Given that a lot of drivers reserve resources for their VFs during
initialization that the pendulum  it would fall on letting the low-level
driver manage the creation and mapping of the NPIV<->VF relationship.

>
> However, for SAS things get really tricky, as we don't have virtual
> SAS IDs. Some vendor was actually planning on doing ACLs in firmware
> (shudder).

Each protocol will be different which means if there is any common
encapsulation is would probably be at the transport level (FC, iSCSI, SAS,
etc.)

>
> And then there is the pci-stub mess.

I presume you'd want to get rid of pci-stub?  What would be the
alternative; just directly unbinding the assignment of the device from
the hypervisor to the virtual guest as it is coming up?

>
> So yes, definitely something to discuss here.
>
> Cheers,
>
> Hannes
>

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.

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

[chetan loke]

On Wed, Mar 14, 2012 at 2:07 PM, Chad Dupuis <chad.dupuis@qlogic.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Chad Dupuis]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]



On Wed, 14 Mar 2012, chetan loke wrote:

> On Wed, Mar 14, 2012 at 2:07 PM, Chad Dupuis <chad.dupuis@qlogic.com> 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.

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

[Boaz Harrosh]

On 03/14/2012 11:07 AM, Chad Dupuis wrote:
> 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.
> 

Please remove any such crap from a public mailing list!!!

I here by declare that: I was not "intended recipient" of this
mail. and I will read, copy, distribute, use this information.
And I will not "delete this message"

And BTW: QLogic just proved it is stupid, because the above is
a legal nothingness!! Which is a pity because they have good
products.

Go away please

:-( Boaz