On 04/10/15 09:19, Bart Van Assche wrote:
On 04/10/15 09:03, Ming Lin wrote:
On Thu, Apr 9, 2015 at 11:54 PM, Bart Van Assche
<bart.vanassche@xxxxxxxxxxx> wrote:
On 04/09/15 09:42, Ming Lin wrote:
diff --git a/include/target/target_core_fabric.h
b/include/target/target_core_fabric.h
index e0a8191..abe3fcb 100644
--- a/include/target/target_core_fabric.h
+++ b/include/target/target_core_fabric.h
@@ -4,8 +4,8 @@
struct target_core_fabric_ops {
struct configfs_subsystem *tf_subsys;
size_t node_acl_size;
+ u8 fabric_proto_ident;
char *(*get_fabric_name)(void);
- u8 (*get_fabric_proto_ident)(struct se_portal_group *);
char *(*tpg_get_wwn)(struct se_portal_group *);
u16 (*tpg_get_tag)(struct se_portal_group *);
u32 (*tpg_get_default_depth)(struct se_portal_group *);
Hello Ming,
Hi Bart,
Please do not use the "fabric_" prefix in the data structure member name.
Since this structure member exists inside the target_core_fabric_ops data
structure it is already clear that it refers to target code and it is not
needed to use the "fabric_" prefix. How about using the name "scsi_protocol"
instead ?
How about "fabric_protocol"? I'm thinking maybe in the future LIO will support
non-scsi protocol also, for example, NVME?
Sorry but I'm not convinced that it would be a good idea to add support
for non-SCSI protocols to LIO. If NVMe-over-fabric support has to be
added upstream it is probably a better idea to create a separate target
project for NVMe-over-fabric.
(replying to my own e-mail)
BTW, the NVMe people need to update their knowledge about SCSI latency.
In every NVMe-over-fabric presentation I have encountered so far I found
the following quote: "Using a SCSI-based protocol for remote NVMe adds
over 100 μs in latency". This is not correct. My own measurements show
that with Linux the SCSI overhead can be as low as 12 μs (see e.g.
http://events.linuxfoundation.org/sites/events/files/slides/Vault%20-%20scsi-mq%20v2.pdf).
Bart.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
