28 Jul, 2011
1 commit
-
There is no need to cache the ptype in fcoe_rcv_info struct as it is never
used anywhere.Signed-off-by: Yi Zou
Tested-by: Ross Brattain
Signed-off-by: Robert Love
Signed-off-by: James Bottomley
28 Jul, 2010
3 commits
-
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
since we need them there and that's included bySigned-off-by: Joe Eykholt
Signed-off-by: Robert Love
Signed-off-by: James Bottomley -
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
Signed-off-by: Robert Love
Signed-off-by: James Bottomley -
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.cinclude/scsi/fc_frame.h:81:9: error: invalid bitfield width, -1.
CC [M] drivers/scsi/fcoe/fcoe.o
CHECK drivers/scsi/fcoe/libfcoe.cinclude/scsi/fc_frame.h:81:9: error: invalid bitfield width, -1.
drivers/scsi/fcoe/libfcoe.c:56:37: error: invalid initializerSigned-off-by: Bart Van Assche
Cc: jeykholt@cisco.com
Signed-off-by: Robert Love
Signed-off-by: James Bottomley
05 Dec, 2009
3 commits
-
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
Signed-off-by: Robert Love
Signed-off-by: James Bottomley -
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
Signed-off-by: Robert Love
Signed-off-by: James Bottomley -
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
Signed-off-by: Robert Love
Signed-off-by: James Bottomley
23 Aug, 2009
1 commit
-
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
Signed-off-by: Robert Love
Signed-off-by: James Bottomley
Signed-off-by: James Bottomley
14 Mar, 2009
1 commit
-
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_deviceSigned-off-by: Yi Zou
Signed-off-by: James Bottomley
30 Dec, 2008
1 commit
-
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
[jejb: added include of delay.h to fix ppc64 compile prob spotted by sfr]
Signed-off-by: James Bottomley
