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
