aboutsummaryrefslogtreecommitdiff
path: root/drivers/scsi/fcoe
AgeCommit message (Collapse)Author
2009-03-13[SCSI] fcoe: fcoe fc crc offload indication by skb->ip_summedYi Zou
If LLD supports FCCRC offload, it should set ip_summed to be CHECKSUM_UNNECESSARY so we don't have to do CRC check again. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-13[SCSI] fcoe: add support to FCoE offload support in fcoe_sw through net_deviceYi Zou
This adds implementation of ddp_setup()/ddp_done() in fcoe_sw for its fcoe_sw_libfc_fcn_templ. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-13[SCSI] fcoe: add support to large send by gso through net_device for fcoe_swYi Zou
Change fcoe_xmit to setup gso for LLD LSO offload as well as CRC offload Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-13[SCSI] fcoe, libfc: check offload features from LLD through netdevYi Zou
This checks if net_devices supports FCoE offload ops in netdev_ops and it if it does, then sets up the corresponding flags in the associated fc_lport. For large send offload, the maximum length supported in one large send is now described by the added lso_max in fc_lport, which is setup initially from netdev->gso_max_size. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-13[SCSI] net, fcoe: add ETH_P_FCOE for Fibre Channel over Ethernet (FCoE)Yi Zou
This adds eth type ETH_P_FCOE for Fibre Channel over Ethernet (FCoE), consequently, the ETH_P_FCOE from fc_fcoe.h and fcoe skb->protocol is not set as ETH_P_FCOE. Signed-off-by: Yi Zou <yi.zou@intel.com> Acked-by: David Miller <davem@davemloft.net> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-10[SCSI] fcoe: Change fcoe receive thread nice value from 19 (lowest priority) ↵Robert Love
to -20 This change makes the fcoe Rx threads have the same nice value as lpfc and qla2xxx Rx threads. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-10[SCSI] fcoe: fix handling of pending queue, prevent out of order frames (v3)Chris Leech
In fcoe_check_wait_queue() the queue length could temporarily drop to 0, before the last frame was successfully sent. This resulted in out of order data frames within a single sequence, leading to IO timeout errors. This builds on the approach from Vasu Dev to only fix the queue management in fcoe_check_wait_queue, where my first patch added locking to the transmit path even when the pending queue was not in use. This patch continues to use fcoe_pending_queue.qlen instead of introducing a new length counter, but takes precautions to ensure it never drops to 0 before the final frame in the queue has successfully been passed to the netdev qdisc layer. It also includes some cleanup of fcoe_check_wait_queue and removes the fcoe_insert_wait_queue(_head) wrapper functions. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-10[SCSI] fcoe: Out of order tx frames was causing several check condition SCSI ↵Vasu Dev
status frames followed by these errors in log. [sdp] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK [sdp] Sense Key : Aborted Command [current] [sdp] Add. Sense: Data phase error This was causing some test apps to exit due to write failure under heavy load. This was due to a race around adding and removing tx frame skb in fcoe_pending_queue, Chris Leech helped me to find that brief unlocking period when pulling skb from fcoe_pending_queue in various contexts (fcoe_watchdog and fcoe_xmit) and then adding skb back into fcoe_pending_queue up on a failed fcoe_start_io could change skb/tx frame order in fcoe_pending_queue. Thanks Chris. This patch allows only single context to pull skb from fcoe_pending_queue at any time to prevent above described ordering issue/race by use of fcoe_pending_queue_active flag. This patch simplified fcoe_watchdog with modified fcoe_check_wait_queue by use of FCOE_LOW_QUEUE_DEPTH instead previously used several conditionals to clear and set lp->qfull. I think FCOE_MAX_QUEUE_DEPTH with FCOE_LOW_QUEUE_DEPTH will work better in re/setting lp->qfull and these could be fine tuned for performance. Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-10[SCSI] fcoe: fix kfree(skb)Roel Kluin
Use kfree_skb instead of kfree for struct sk_buff pointers. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-10[SCSI] fcoe: Correct fcoe_transports initialization vs. registrationRobert Love
The registration function shouldn't initialize the mutex or list head. The fcoe SW transport should initialize itself before registering. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-10[SCSI] fcoe: Use setup_timer() and mod_timer()Robert Love
Use helper functions for watchdog timer setup. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-10[SCSI] libfc, fcoe: Remove unnecessary cast by removing inline wrapperRobert Love
Comment from "Andrew Morton <akpm@linux-foundation.org>" > +{ > + return (struct fcoe_softc *)lport_priv(lp); unneeded/undesirable cast of void*. There are probably zillions of instances of this - there always are. This whole inline function was unnecessary. The FCoE layer knows that it's data structure is stored in the lport private data, it can just access it from lport_priv(). Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-10[SCSI] libfc, fcoe: Cleanup function formatting and minor typosRobert Love
1) There were a few functions with a strange layout, i.e. all arguments on the second line, when not necessary. Where ever possible I moved the return value to the same line as the function name. However, when the line was too long to have a single argument on the same line I moved the return value to above line. For example: <short return> <function name>(<arg 1>, <arg2>) and <very long return value> <function name>(<arg1>, <arg2>) 2) Removed one extra whitespace line 3) Fixed two typos Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-10[SCSI] libfc, fcoe: Fix kerneldoc commentsRobert Love
1) Added '()' for function names in kerneldoc comments 2) Changed comment bookends from '**/' to '*/'. The comment on the the mailing list was that '**/' "is consistently unconventional. Not wrong, just odd." The Documentation/kernel-doc-nano-HOWTO.txt states that kerneldoc comment blocks should end with '**/' but most (if not all) instance I found under drivers/scsi/ were only using the '*/' so I converted to that style. 3) Removed incorrect linebreaks in kerneldoc comments where found 4) Removed a few unnecessary blank comment lines in kerneldoc comment blocks Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2009-03-06[SCSI] libfc, fcoe: fixed locking issues with lport->lp_mutex around ↵Vasu Dev
lport->link_status The fcoe_xmit could call fc_pause in case the pending skb queue len is larger than FCOE_MAX_QUEUE_DEPTH, the fc_pause was trying to grab lport->lp_muex to change lport->link_status and that had these issues :- 1. The fcoe_xmit was getting called with bh disabled, thus causing "BUG: scheduling while atomic" when grabbing lport->lp_muex with bh disabled. 2. fc_linkup and fc_linkdown function calls lport_enter function with lport->lp_mutex held and these enter function in turn calls fcoe_xmit to send lport related FC frame, e.g. fc_linkup => fc_lport_enter_flogi to send flogi req. In this case grabbing the same lport->lp_mutex again in fc_puase from fcoe_xmit would cause deadlock. The lport->lp_mutex was used for setting FC_PAUSE in fcoe_xmit path but FC_PAUSE bit was not used anywhere beside just setting and clear this bit in lport->link_status, instead used a separate field qfull in fc_lport to eliminate need for lport->lp_mutex to track pending queue full condition and in turn avoid above described two locking issues. Also added check for lp->qfull in fc_fcp_lport_queue_ready to trigger SCSI_MLQUEUE_HOST_BUSY when lp->qfull is set to prevent more scsi-ml cmds while lp->qfull is set. This patch eliminated FC_LINK_UP and FC_PAUSE and instead used dedicated fields in fc_lport for this, this simplified all related conditional code. Also removed fc_pause and fc_unpause functions and instead used newly added lport->qfull directly in fcoe. Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2008-12-30[SCSI] fcoe: fix incorrect use of struct moduleJames Bottomley
This structure may not be defined if CONFIG_MODULE=n, so never deref it. Change uses of module->name to module_name(module) and corrects some dyslexic printks and docbook comments. Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2008-12-29[SCSI] fcoe: Fibre Channel over EthernetRobert Love
Encapsulation protocol for running Fibre Channel over Ethernet interfaces. Creates virtual Fibre Channel host adapters using libfc. This layer is the LLD to the scsi-ml. It allocates the Scsi_Host, utilizes libfc for Fibre Channel protocol processing and interacts with netdev to send/receive Ethernet packets. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>