> This patch contains code that interfaces with libfc, libfcoe > and cnic modules to create FCoE instances, send/receive > non-offload FIP/FCoE packets, listen to link events, etc. > > Signed-off-by: Bhanu Prakash Gollapudi <bprakash@xxxxxxxxxxxx> > --- > drivers/scsi/Kconfig | 1 + > drivers/scsi/Makefile | 1 + > drivers/scsi/bnx2fc/Kconfig | 11 + > drivers/scsi/bnx2fc/Makefile | 3 + > drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 2320 > +++++++++++++++++++++++++++++++++++++ > 5 files changed, 2336 insertions(+), 0 deletions(-) > create mode 100644 drivers/scsi/bnx2fc/Kconfig > create mode 100644 drivers/scsi/bnx2fc/Makefile > create mode 100644 drivers/scsi/bnx2fc/bnx2fc_fcoe.c > > <-- snip --> > > + > +unsigned long bnx2fc_debug_level; > +module_param(bnx2fc_debug_level, long, 0644); > +module_param_call(create, bnx2fc_create, NULL, (void *)FIP_MODE_FABRIC, > + S_IWUSR); > +__MODULE_PARM_TYPE(create, "string"); > +MODULE_PARM_DESC(create, " Creates fcoe instance on a ethernet > interface"); > +module_param_call(destroy, bnx2fc_destroy, NULL, NULL, S_IWUSR); > +__MODULE_PARM_TYPE(destroy, "string"); > +MODULE_PARM_DESC(destroy, " Destroys fcoe instance on a ethernet > interface"); > + //I sent this earlier to open-fcoe.org mailing list and realized it was temporarily down, so resend this here, apologize if you get it multiple times. I understand that fcoe.ko is not needed here, but the above also indicates that the create/destroy will not be going through the existing fcoe-utils which uses sysfs entries of the fcoe module. I think it will be nice for everyone to use fcoe-utils as the open-fcoe user space tool. However, the existing fcoe.c does not offer that flexibility, where I think we have to separate the fcoe.c to provide a fcoe transport layer so vendor fcoe hba can plug in, where the existing fcoe.c is the sw fcoe transport and plugged in by default. All fcoe transports are registered when they are loaded, when fcoe_create() gets called from sysfs, it passes to the fcoe transport to look up from the registered transports, whoever thinks the netdev is associated with its hw will take over from there, fcoe_destroy() is similar. The default transport is the sw fcoe hba in current fcoe.c will be called upon if no registered fcoe transport can provide offload there. As the mod params are in fcoe.c, I think we can move create/destroy to libfcoe, and, yeah, that does require change in fcoe-utils as well, but that would allow fcoe.c be the pure sw fcoe transport. There will be functions in current fcoe.c that can be exported so both sw or hw fcoe transport can use, reducing the code size. The sw fcoe transport can plug in as vendor's transport in the same way through fcoe transport registration, so fcoe.ko will not be required for any vendors who has their fcoe transport implementation, e.g., bnx2fc_fcoe. I hope this makes sense, I do think this logic would work nicely for any fcoe hba to provide the same user interface on top of given network interface name via fcoe-util, which is already pretty well maintained and tested, with full DCB support as well. I am hoping we can move towards this direction, if not now. Thanks, yi -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
