Joe Eykholt, on 02/12/2010 04:07 AM wrote: > This patch adds a new target module for SCST and libfc > that accepts FCP requests from libfc HBAs running Fibre Channel > over Ethernet (FCoE) and passes them to SCST. I'm hoping that > this can be included in the SCST tree eventually.
It's very nice to see this driver! > This is mostly to gather comments. It isn't at all well tested. > It works with simple read/write tests with vdisk targets. > It doesn't use any libfc offloads as of yet. Task management > and error cases haven't been tested. > > It relies on a set of patches just submitted to open-fcoe.org > to add hooks for target providers like this. > > It has only been used under the 2.6.33-rc4 kernel. > > The known issues are: > * task management > * could offload or allocate buffers to avoid copies Which copies do you mean? > * doesn't handle target timeouts. > * completion handling not done (no tape support yet) > * exchanges not held around for REC/SRR after response sent > * SRR not tested > * error handling could be better > * need way of sending LOGO when disabling I/T nexus. > * Asynchronous Event Notification (AEN) not handled. > > Management is similar to the qla2x00t target. I tested this > with /sys only, but management uses the common SCST code, so > /proc may work as well. /sys only is OK. /proc is going to die soon. > Signed-off-by: Joe Eykholt <[email protected]> After a brief review for the current state of development it looks very good! I noticed only few issues: - ft_send_xfer_rdy() uses cmd->data_len, but should use scst_cmd_get_bufflen(cmd) instead. Data_len is internal variable for commands which need data buffer bigger than data to transfer. Example of such commands is VERIFY commands, which, if BYTCHK set to zero, read data from media, but not transfer them anywhere. - The driver in many cases directly accesses internal data of SCST structures. This isn't an encouraged practice. - When sessions are being closed I don't see the driver anywhere refuses new coming commands or blocked them. Without it under high load the closing can take too long. Also, ft_scst_template.threads_num = 4 means that ft_send_response() is blocking, i.e. doesn't return until all data are sent. Correct? Could you write a small README how to use this driver for people not familiar with FCoE like me? I'd like to try it. Does this driver support P2P mode? Would you like I commit it somewhere in trunk/fcoe? Or trunk/fcst? Then I can grant you commit rights to it. We need the driver can be compiled inside SCST SVN tree as a module. Don't worry how to compile it inside kernel. We have script generate-kernel-patch, which takes care of it. Thanks, Vlad _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
