[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] 答复: Re: [RFC] virtio-fc: draft idea of virtual fibre c
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] 答复: Re: [RFC] virtio-fc: draft idea of virtual fibre channel HBA |
Date: |
Tue, 16 May 2017 18:22:17 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 |
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