Re: [Qemu-devel] 答复： Re: [RFC] virtio-fc: draft idea of virtual fibre channel HBA

[Hannes Reinecke]

On 05/16/2017 06:22 PM, Paolo Bonzini wrote:
> Pruning to sort out the basic disagreements.
> 
> On 16/05/2017 17:22, Hannes Reinecke wrote:
>>> That depends on how you would like to do controller passthrough in
>>> general.  iSCSI doesn't have the 64-bit target ID, and doesn't have
>>> (AFAIK) hot-plug/hot-unplug support, so it's less important than FC.
>>>
>> iSCSI has its 'iqn' string, which is defined to be a 256-byte string.
>> Hence the number 
>> And if we're updating virtio anyway, we could as well update it to carry
>> _all_ possible scsi IDs.
> 
> Yes, but one iSCSI connection maps to one initiator and target IQN.
> It's not like FC where each frame can specify its own initiator ID.
> 
Sure. But updating the format to hold _any_ SCSI Name would allow us to
reflect the actual initiator port name used by the host.
So the guest could be
>>>> (3) would be feasible, as it would effectively mean 'just' to update the
>>>> current NPIV mechanism. However, this would essentially lock us in for
>>>> FC; any other types (think NVMe) will require yet another solution.
>>> An FC-NVMe driver could also expose the same vhost interface, couldn't it?
>>> FC-NVMe doesn't have to share the Linux code; but sharing the virtio 
>>> standard
>>> and the userspace ABI would be great.
>>>
>>> In fact, the main advantage of virtio-fc would be that (if we define it 
>>> properly)
>>> it could be reused for FC-NVMe instead of having to extend e.g. virtio-blk.
>>> For example virtio-scsi has request, to-device payload, response, 
>>> from-device
>>> payload.  virtio-fc's request format could be the initiator and target port
>>> identifiers, followed by FCP_CMD, to-device payload, FCP_RSP, from-device
>>> payload.
>>>
>> As already said: We do _not_ have access to the FCP frames.
>> So designing a virtio-fc protocol will only work for libfc-based HBAs,
>> namely fnic, bnx2fc, and fcoe.
>> Given that the future of FCoE is somewhat unclear I doubt it's a good
>> idea to restrict ourselves to that.
> 
> I understand that.  It doesn't have to be a 1:1 match with FCP frames or
> even IUs; in fact the above minimal example is not (no OXID/RXID and no
> FCP_XFER_RDY IU are just the first two things that come to mind).
> 
> The only purpose is to have a *transport* that is (roughly speaking)
> flexible enough to support future NPIV usecases which will certainly
> include FC-NVMe.  In other words: I'm inventing my own cooked FCP
> format, but I might as well base it on FCP itself as much as possible.
> 
Weeelll ... I don't want to go into nit-picking here, but FC-NVMe is
_NOT_ FCP. In fact, it's a different FC-4 provider with its own set of
FC-4 commands etc.

> Likewise, I'm not going to even mention ELS, but we would need _some_
> kind of protocol to query name servers, receive state change
> notifications, and get service parameters.  No idea yet how to do that,
> probably something similar to virtio-scsi control and event queues, but
> why not make the requests/responses look a little like PLOGI and PRLI?
> 
And my idea here is to keep virtio-scsi as the basic mode of (command)
transfer, but add a set of transport management commands which would
allow us to do things like:
- port discovery / scan
- port instantiation / login
- port reset
- transport link notification / status check
- transport reset

Those could be defined transport independently; and the neat thing is
they could even be made to work with the current NPIV implementation
with some tooling.
And we could define things such that all current transport protocols can
be mapped onto it.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Teamlead Storage & Networking
address@hidden                                 +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)