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

[Paolo Bonzini]

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.

>>> (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.

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?

Thanks,

Paolo