summaryrefslogtreecommitdiff
path: root/include/scsi/fc_frame.h
AgeCommit message (Collapse)Author
2011-07-28[SCSI] fcoe: remove unused ptype field in fcoe_rcv_infoYi Zou
There is no need to cache the ptype in fcoe_rcv_info struct as it is never used anywhere. Signed-off-by: Yi Zou <yi.zou@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2010-07-28[SCSI] libfc: add fc_frame_sid() and fc_frame_did() functionsJoe Eykholt
To pave the way for eliminating exchanges from incoming requests, add simple inline fc_frame_sid() and fc_frame_did() functions which get the FC_IDs from the frame header. This can be almost as efficient as getting them from the sequence/exchange. Move ntohll, htonll, ntoh24 and hton24 to <scsi/fc_frame.h> since we need them there and that's included by <scsi/libfc.h> Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-28[SCSI] libfc: track FIP exchangesJoe Eykholt
When an exchange is received with a FIP encapsulation, we need to know that the response must be sent via FIP and what the original ELS opcode was. This becomes important for VN2VN mode, where we may receive FLOGI or LOGO from several peer VN_ports, and the LS_ACC or LS_RJT must be sent FIP-encapsulated with the correct sub-type. Add a field to the struct fc_frame, fr_encaps, to indicate the encapsulation values. That term is chosen to be neutral and LLD-agnostic in case non-FCoE/FIP LLDs might find it useful. The frame fr_encaps is transferred from the ingress frame to the exchange by fc_exch_recv_req(), and back to the outgoing frame by fc_seq_send(). This is taking the last byte in the skb->cb array. If needed, we could combine the info in sof, eof, flags, and encaps together into one field, but it'd be better to do that if and when its needed. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-28[SCSI] fcoe: make it possible to verify fcoe with sparseBart Van Assche
Analyzing fcoe with sparse currently fails. This is because struct fcoe_rcv_info contains two enum members that have been declared with __attribute__((packed)). Apparently gcc honors this attribute while sparse ignores it. The result is that sizeof(struct fcoe_rcv_info) == sizeof(struct sk_buff::cb) == 48 on a 64-bit system according to gcc, but not according to sparse. The patch below modifies the definition of struct fcoe_rcv_info such that gcc and sparse interpret this structure definition in the same way. The current sparse output is as follows: $ cd linux-2.6.34 $ make C=2 M=drivers/scsi/fcoe modules CHECK drivers/scsi/fcoe/fcoe.c include/scsi/fc_frame.h:81:9: error: invalid bitfield width, -1. CC [M] drivers/scsi/fcoe/fcoe.o CHECK drivers/scsi/fcoe/libfcoe.c include/scsi/fc_frame.h:81:9: error: invalid bitfield width, -1. drivers/scsi/fcoe/libfcoe.c:56:37: error: invalid initializer Signed-off-by: Bart Van Assche <bart.vanassche@gmail.com> Cc: jeykholt@cisco.com Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe, libfc: use single frame allocation APIVasu Dev
Cleans up frame allocation APIs to have just single fc_frame_alloc API. Removes _fc_frame_alloc, renames __fc_frame_alloc to _fc_frame_alloc. Modifies fc_fcp_send_data for removed _fc_frame_alloc, fc_fcp_send_data was the only user of removed _fc_frame_alloc. Also Adds check in fc_frame_alloc to do mod by 4 for only non-zero len value. This patch is prep work to fix can_queue reducing in next patch. Single fc_frame_alloc API helps in fixing can_queue reducing in next patch. 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@suse.de>
2009-12-04[SCSI] libfcoe, fcoe: libfcoe NPIV supportChris Leech
The FIP code in libfcoe needed several changes to support NPIV 1) dst_src_addr needs to be managed per-n_port-ID for FPMA fabrics with NPIV enabled. Managing the MAC address is now handled in fcoe, with some slight changes to update_mac() and a new get_src_addr() function pointer. 2) The libfc elsct_send() hook is used to setup FCoE specific response handlers for FIP encapsulated ELS exchanges. This lets the FCoE specific handling know which VN_Port the exchange is for, and doesn't require tracking OX_IDs. It might be possible to roll back to the full FIP frame in these, but for now I've just stashed the contents of the MAC address descriptor in the skb context block for later use. Also, because fcoe_elsct_send() just passes control on to fc_elsct_send(), all transmits still come through the normal frame_send() path. 3) The NPIV changes added a mutex hold in the keep alive sending, the lport mutex is protecting the vport list. We can't take a mutex from a timer, so move the FIP keep alive logic to the link work struct. 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@suse.de>
2009-12-04[SCSI] libfc: Fix frags in frame exceeding SKB_MAX_FRAGS in fc_fcp_send_dataYi Zou
In case of sequence offload, in fc_fcp_send_data(), the skb_fill_page_info() called may end up adding more frags to the skb_shinfo(fp_skb(fp))->frags[], exceeding SKB_MAX_FRAGS, this eventually corrupts the memory. I am adding the FR_FRAME_SG_LEN back, but as SKB_MAX_FRAGS -1, leaving 1 for our fcoe_eof_crc page. And send will be broken into multiple large sends if the frame already contains more frags than skb handle. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-08-22[SCSI] libfc: Remove FC_FRAME_SG_LEN in fc_fcp_send_dataYi Zou
FC_FRAME_SG_LEN is 4 which is too small when offload is enabled. Actually, the WARN_ON() in fc_fcp_send_data() should be: WARN_ON(skb_shinfo(fp_skb(fp))->nr_frags > MAX_SKB_FRAGS); But since we will not get anything more than 64K anyway, so there is no need to do this anyway here. Therefore, I am getting rid of FC_FRAME_SG_LEN here and the WARN_ON here. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-03-13[SCSI] libfc: add support of large receive offload by ddp in fc_fcpYi Zou
When LLD supports direct data placement (ddp) for large receive of an scsi i/o coming into fc_fcp, we call into libfc_function_template's ddp_setup() to prepare for a ddp of large receive for this read I/O. When I/O is complete, we call the corresponding ddp_done() to get the length of data ddped as well as to let LLD do clean up. fc_fcp_ddp_setup()/fc_fcp_ddp_done() are added to setup and complete a ddped read I/O described by the given fc_fcp_pkt. They would call into corresponding ddp_setup/ddp_done implemented by the fcoe layer. Eventually, fcoe layer calls into LLD's ddp_setup/ddp_done provided through net_device Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2008-12-29[SCSI] libfc: A modular Fibre Channel libraryRobert Love
libFC is composed of 4 blocks supported by an exchange manager and a framing library. The upper 4 layers are fc_lport, fc_disc, fc_rport and fc_fcp. A LLD that uses libfc could choose to either use libfc's block, or using the transport template defined in libfc.h, override one or more blocks with its own implementation. The EM (Exchange Manager) manages exhcanges/sequences for all commands- ELS, CT and FCP. The framing library frames ELS and CT commands. The fc_lport block manages the library's representation of the host's FC enabled ports. The fc_disc block manages discovery of targets as well as handling changes that occur in the FC fabric (via. RSCN events). The fc_rport block manages the library's representation of other entities in the FC fabric. Currently the library uses this block for targets, its peer when in point-to-point mode and the directory server, but can be extended for other entities if needed. The fc_fcp block interacts with the scsi-ml and handles all I/O. Signed-off-by: Robert Love <robert.w.love@intel.com> [jejb: added include of delay.h to fix ppc64 compile prob spotted by sfr] Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>