<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include/scsi/libfcoe.h, branch v3.0.86</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include/scsi/libfcoe.h?h=v3.0.86</id>
<link rel='self' href='https://git.amat.us/linux/atom/include/scsi/libfcoe.h?h=v3.0.86'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2011-03-01T00:33:12Z</updated>
<entry>
<title>[SCSI] libfcoe: Move FCOE_MTU definition from fcoe.h to libfcoe.h</title>
<updated>2011-03-01T00:33:12Z</updated>
<author>
<name>Bhanu Prakash Gollapudi</name>
<email>bprakash@broadcom.com</email>
</author>
<published>2011-02-25T23:03:12Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f4d2b2b6ea8abd0df72a31b4724522a277af6a6c'/>
<id>urn:sha1:f4d2b2b6ea8abd0df72a31b4724522a277af6a6c</id>
<content type='text'>
both fcoe and bnx2fc drivers can access the common definition of
FCOE_MTU.

Signed-off-by: Bhanu Prakash Gollapudi &lt;bprakash@broadcom.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
</content>
</entry>
<entry>
<title>[SCSI] libfcoe: Move common code from fcoe to libfcoe module</title>
<updated>2011-02-12T17:18:18Z</updated>
<author>
<name>Bhanu Prakash Gollapudi</name>
<email>bprakash@broadcom.com</email>
</author>
<published>2011-01-29T00:05:37Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8597ae8bfe35f5e438b00ba5df852e97ebe1ac23'/>
<id>urn:sha1:8597ae8bfe35f5e438b00ba5df852e97ebe1ac23</id>
<content type='text'>
To facilitate LLDDs to reuse the code, skb queue related functions are moved to
libfcoe, so that both fcoe and bnx2fc drivers can use them. The common structures
fcoe_port, fcoe_percpu_s are moved to libfcoe. fcoe_port will now have an
opaque pointer that points to corresponding driver's interface structure.
Also, fcoe_start_io and fcoe_fc_crc are moved to libfcoe.

As part of this change, fixed fcoe_start_io to return ENOMEM if
skb_clone fails.

Signed-off-by: Bhanu Prakash Gollapudi &lt;bprakash@broadcom.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
</content>
</entry>
<entry>
<title>[SCSI] libfcoe: add fcoe_transport structure defines to include/scsi/libfcoe.h</title>
<updated>2011-02-12T17:05:29Z</updated>
<author>
<name>Yi Zou</name>
<email>yi.zou@intel.com</email>
</author>
<published>2011-01-29T00:04:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0ade7d290b6aa8b1626a4077b853c02cd12415c2'/>
<id>urn:sha1:0ade7d290b6aa8b1626a4077b853c02cd12415c2</id>
<content type='text'>
add the fcoe_transport struct to the common libfcoe.h header so all fcoe
transport provides can use it to attach itself as an fcoe transport. This
is the header part, and the next patch will be the transport code itself.

Signed-off-by: Yi Zou &lt;yi.zou@intel.com&gt;
Signed-off-by: Bhanu Prakash Gollapudi &lt;bprakash@broadcom.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
</content>
</entry>
<entry>
<title>[SCSI] libfcoe: retry rejected FLOGI to another FCF if possible</title>
<updated>2010-12-21T18:24:32Z</updated>
<author>
<name>Joe Eykholt</name>
<email>jeykholt@cisco.com</email>
</author>
<published>2010-12-01T00:19:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=794d98e77f5901ceded697f1633463e88f078038'/>
<id>urn:sha1:794d98e77f5901ceded697f1633463e88f078038</id>
<content type='text'>
Switches using multiple-FCFs may reject FLOGI in order to
balance the load between multiple FCFs.  Even though the FCF
was available, it may have more load at the point we actually
send the FLOGI.

If the FLOGI fails, select a different FCF
if possible, among those with the same priority.  If no other
FCF is available, just deliver the reject to libfc for retry.

Signed-off-by: Joe Eykholt &lt;jeykholt@cisco.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
</content>
</entry>
<entry>
<title>[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support</title>
<updated>2010-07-28T14:05:56Z</updated>
<author>
<name>Joe Eykholt</name>
<email>jeykholt@cisco.com</email>
</author>
<published>2010-07-20T22:20:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e10f8c667b874a57512c936089092a3d1ef7ab8a'/>
<id>urn:sha1:e10f8c667b874a57512c936089092a3d1ef7ab8a</id>
<content type='text'>
The FC-BB-6 committee is proposing a new FIP usage model called
VN_port to VN_port mode.  It allows VN_ports to discover each other
over a loss-free L2 Ethernet without any FCF or Fibre-channel fabric
services.  This is point-to-multipoint.  There is also a variant
of this called point-to-point which provides for making sure there
is just one pair of ports operating over the Ethernet fabric.

We add these new states:  VNMP_START, _PROBE1, _PROBE2, _CLAIM, and _UP.
These usually go quickly in that sequence.  After waiting a random
amount of time up to 100 ms in START, we select a pseudo-random
proposed locally-unique port ID and send out probes in states PROBE1
and PROBE2, 100 ms apart.  If no probe responses are heard, we
proceed to CLAIM state 400 ms later and send a claim notification.
We wait another 400 ms to receive claim responses, which give us
a list of the other nodes on the network, including their FC-4
capabilities.  After another 400 ms we go to VNMP_UP state and
should start interoperating with any of the nodes for whic we
receivec claim responses.  More details are in the spec.j

Add the new mode as FIP_MODE_VN2VN.  The driver must specify
explicitly that it wants to operate in this mode.  There is
no automatic detection between point-to-multipoint and fabric
mode, and the local port initialization is affected, so it isn't
anticipated that there will ever be any such automatic switchover.

It may eventually be possible to have both fabric and VN2VN
modes on the same L2 network, which may be done by two separate
local VN_ports (lports).

When in VN2VN mode, FIP replaces libfc's fabric-oriented discovery
module with its own simple code that adds remote ports as they
are discovered from incoming claim notifications and responses.
These hooks are placed by fcoe_disc_init().

A linear list of discovered vn_ports is maintained under the
fcoe_ctlr struct.  It is expected to be short for now, and
accessed infrequently.  It is kept under RCU for lock-ordering
reasons.  The lport and/or rport mutexes may be held when we
need to lookup a fcoe_vnport during an ELS send.

Change fcoe_ctlr_encaps() to lookup the destination vn_port in
the list of peers for the destination MAC address of the
FIP-encapsulated frame.

Add a new function fcoe_disc_init() to initialize just the
discovery portion of libfcoe for VN2VN mode.

Signed-off-by: Joe Eykholt &lt;jeykholt@cisco.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
</content>
</entry>
<entry>
<title>[SCSI] libfcoe: fcoe: fnic: change fcoe_ctlr_init interface to specify mode</title>
<updated>2010-07-28T14:05:52Z</updated>
<author>
<name>Joe Eykholt</name>
<email>jeykholt@cisco.com</email>
</author>
<published>2010-07-20T22:19:58Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3d902ac09a2812b359edf633425d1327a18399e9'/>
<id>urn:sha1:3d902ac09a2812b359edf633425d1327a18399e9</id>
<content type='text'>
There are three modes that libfcoe currently supports, and a new one
is coming.  Change the fcoe_ctlr_init() interface to add the mode
desired.  This should not change any functionality.

Signed-off-by: Joe Eykholt &lt;jeykholt@cisco.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
</content>
</entry>
<entry>
<title>[SCSI] libfcoe: convert FIP to lock with mutex instead of spin lock</title>
<updated>2010-07-28T14:05:51Z</updated>
<author>
<name>Joe Eykholt</name>
<email>jeykholt@cisco.com</email>
</author>
<published>2010-07-20T22:19:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=fdb068c6cd6e30d43664f856d3530715a5742713'/>
<id>urn:sha1:fdb068c6cd6e30d43664f856d3530715a5742713</id>
<content type='text'>
It turns out most of the FIP work is now done from worker threads
or process context now, so there's no need to use a spin lock.

Change to use mutex instead of spin lock and delayed_work instead
of a timer.

This will make it nicer for the VN_port to VN_port feature that
will interact more with the libfc layers requiring that
spinlocks not be held.

Signed-off-by: Joe Eykholt &lt;jeykholt@cisco.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
</content>
</entry>
<entry>
<title>[SCSI] fcoe: adds src and dest mac address checking for fcoe frames</title>
<updated>2010-07-28T14:05:47Z</updated>
<author>
<name>Vasu Dev</name>
<email>vasu.dev@intel.com</email>
</author>
<published>2010-07-20T22:19:32Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=519e5135e2537c9dbc1cbcc0891b0a936ff5dcd2'/>
<id>urn:sha1:519e5135e2537c9dbc1cbcc0891b0a936ff5dcd2</id>
<content type='text'>
This is  per FC-BB-5 Annex-D recommendation and per that
if address checking fails then drop the frame.

FIP code paths are already doing this so only needed for fcoe
frames.

The src address checking is limited to only fip mode since
this might break non-fip mode used in p2p due to used OUI
based addressing in some p2p code paths, going forward FIP
will be the only mode, therefore limited this to only FIP
mode so that it won't break non-fip p2p mode for now.

-v2
Removes FCOE packet type checking since fcoe_rcv is
registered to receive only FCoE type packets from netdev
and it is already checked by netdev.

Signed-off-by: Vasu Dev &lt;vasu.dev@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
</content>
</entry>
<entry>
<title>[SCSI] fcoe, fnic, libfc: increased CDB size to 16 bytes for fcoe.</title>
<updated>2010-04-11T19:02:39Z</updated>
<author>
<name>Vasu Dev</name>
<email>vasu.dev@intel.com</email>
</author>
<published>2010-04-09T21:22:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=da87bfab8a7e6cfd0e1e5c5874d7fd4f7d11e64e'/>
<id>urn:sha1:da87bfab8a7e6cfd0e1e5c5874d7fd4f7d11e64e</id>
<content type='text'>
No reason to restrict CDB size to 12 bytes in fcoe, so
increased to 16 so that 16 bytes SCSI CDB doesn't fail.

Uses common define to set max_cmd_len for fcoe and fnic,
fnic is already setting max_cmd_len to 16.

sg_readcap -l fails without this fix.

Signed-off-by: Vasu Dev &lt;vasu.dev@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
</content>
</entry>
<entry>
<title>[SCSI] libfcoe: eliminate unused link and last_link fields</title>
<updated>2010-04-11T14:23:38Z</updated>
<author>
<name>Joe Eykholt</name>
<email>jeykholt@cisco.com</email>
</author>
<published>2010-03-13T00:08:23Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4291365784c9622c9d643cf23421f9c7b9662d71'/>
<id>urn:sha1:4291365784c9622c9d643cf23421f9c7b9662d71</id>
<content type='text'>
The link and last_link fields in the fcoe_ctlr struct are no
longer useful, since they are always set to the same value,
and FIP always calls libfc to pass link information to the lport.

Eliminate those fields and rename link_work to timer_work, since
it no longer has any link change work to do.

Thanks to Brian Uchino for discovering this issue.

Signed-off-by: Joe Eykholt &lt;jeykholt@cisco.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@suse.de&gt;
</content>
</entry>
</feed>
