2019-05-29 23:57:49 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2008-12-09 23:10:24 +00:00
|
|
|
/*
|
2009-03-17 18:42:40 +00:00
|
|
|
* Copyright (c) 2008-2009 Cisco Systems, Inc. All rights reserved.
|
|
|
|
|
* Copyright (c) 2007-2008 Intel Corporation. All rights reserved.
|
2008-12-09 23:10:24 +00:00
|
|
|
*
|
|
|
|
|
* Maintained at www.Open-FCoE.org
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _LIBFCOE_H
|
|
|
|
|
#define _LIBFCOE_H
|
|
|
|
|
|
2009-03-17 18:42:40 +00:00
|
|
|
#include <linux/etherdevice.h>
|
|
|
|
|
#include <linux/if_ether.h>
|
2008-12-09 23:10:24 +00:00
|
|
|
#include <linux/netdevice.h>
|
|
|
|
|
#include <linux/skbuff.h>
|
2009-03-17 18:42:40 +00:00
|
|
|
#include <linux/workqueue.h>
|
2022-05-06 10:57:55 +00:00
|
|
|
#include <linux/local_lock.h>
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
#include <linux/random.h>
|
2008-12-09 23:10:24 +00:00
|
|
|
#include <scsi/fc/fc_fcoe.h>
|
|
|
|
|
#include <scsi/libfc.h>
|
2012-05-23 02:06:21 +00:00
|
|
|
#include <scsi/fcoe_sysfs.h>
|
2008-12-09 23:10:24 +00:00
|
|
|
|
2010-04-09 21:22:59 +00:00
|
|
|
#define FCOE_MAX_CMD_LEN 16 /* Supported CDB length */
|
|
|
|
|
|
2011-02-25 23:03:12 +00:00
|
|
|
/*
|
|
|
|
|
* Max MTU for FCoE: 14 (FCoE header) + 24 (FC header) + 2112 (max FC payload)
|
|
|
|
|
* + 4 (FC CRC) + 4 (FCoE trailer) = 2158 bytes
|
|
|
|
|
*/
|
|
|
|
|
#define FCOE_MTU 2158
|
|
|
|
|
|
2009-03-17 18:42:40 +00:00
|
|
|
/*
|
|
|
|
|
* FIP tunable parameters.
|
|
|
|
|
*/
|
|
|
|
|
#define FCOE_CTLR_START_DELAY 2000 /* mS after first adv. to choose FCF */
|
2019-07-21 12:50:39 +00:00
|
|
|
#define FCOE_CTLR_SOL_TOV 2000 /* min. solicitation interval (mS) */
|
2009-03-17 18:42:40 +00:00
|
|
|
#define FCOE_CTLR_FCF_LIMIT 20 /* max. number of FCF entries */
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
#define FCOE_CTLR_VN2VN_LOGIN_LIMIT 3 /* max. VN2VN rport login retries */
|
2009-03-17 18:42:40 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* enum fip_state - internal state of FCoE controller.
|
|
|
|
|
* @FIP_ST_DISABLED: controller has been disabled or not yet enabled.
|
|
|
|
|
* @FIP_ST_LINK_WAIT: the physical link is down or unusable.
|
|
|
|
|
* @FIP_ST_AUTO: determining whether to use FIP or non-FIP mode.
|
|
|
|
|
* @FIP_ST_NON_FIP: non-FIP mode selected.
|
|
|
|
|
* @FIP_ST_ENABLED: FIP mode selected.
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
* @FIP_ST_VNMP_START: VN2VN multipath mode start, wait
|
|
|
|
|
* @FIP_ST_VNMP_PROBE1: VN2VN sent first probe, listening
|
|
|
|
|
* @FIP_ST_VNMP_PROBE2: VN2VN sent second probe, listening
|
|
|
|
|
* @FIP_ST_VNMP_CLAIM: VN2VN sent claim, waiting for responses
|
|
|
|
|
* @FIP_ST_VNMP_UP: VN2VN multipath mode operation
|
2009-03-17 18:42:40 +00:00
|
|
|
*/
|
|
|
|
|
enum fip_state {
|
|
|
|
|
FIP_ST_DISABLED,
|
|
|
|
|
FIP_ST_LINK_WAIT,
|
|
|
|
|
FIP_ST_AUTO,
|
|
|
|
|
FIP_ST_NON_FIP,
|
|
|
|
|
FIP_ST_ENABLED,
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
FIP_ST_VNMP_START,
|
|
|
|
|
FIP_ST_VNMP_PROBE1,
|
|
|
|
|
FIP_ST_VNMP_PROBE2,
|
|
|
|
|
FIP_ST_VNMP_CLAIM,
|
|
|
|
|
FIP_ST_VNMP_UP,
|
2009-03-17 18:42:40 +00:00
|
|
|
};
|
|
|
|
|
|
2010-07-20 22:19:58 +00:00
|
|
|
/*
|
|
|
|
|
* Modes:
|
|
|
|
|
* The mode is the state that is to be entered after link up.
|
|
|
|
|
* It must not change after fcoe_ctlr_init() sets it.
|
|
|
|
|
*/
|
2016-07-04 08:29:19 +00:00
|
|
|
enum fip_mode {
|
2019-02-15 12:19:20 +00:00
|
|
|
FIP_MODE_AUTO,
|
2016-07-04 08:29:19 +00:00
|
|
|
FIP_MODE_NON_FIP,
|
|
|
|
|
FIP_MODE_FABRIC,
|
|
|
|
|
FIP_MODE_VN2VN,
|
|
|
|
|
};
|
2010-07-20 22:19:58 +00:00
|
|
|
|
2009-03-17 18:42:40 +00:00
|
|
|
/**
|
2009-11-03 19:47:45 +00:00
|
|
|
* struct fcoe_ctlr - FCoE Controller and FIP state
|
|
|
|
|
* @state: internal FIP state for network link and FIP or non-FIP mode.
|
2009-11-03 19:48:11 +00:00
|
|
|
* @mode: LLD-selected mode.
|
2009-11-03 19:47:45 +00:00
|
|
|
* @lp: &fc_lport: libfc local port.
|
|
|
|
|
* @sel_fcf: currently selected FCF, or NULL.
|
|
|
|
|
* @fcfs: list of discovered FCFs.
|
2013-09-05 07:47:27 +00:00
|
|
|
* @cdev: (Optional) pointer to sysfs fcoe_ctlr_device.
|
2009-11-03 19:47:45 +00:00
|
|
|
* @fcf_count: number of discovered FCF entries.
|
|
|
|
|
* @sol_time: time when a multicast solicitation was last sent.
|
|
|
|
|
* @sel_time: time after which to select an FCF.
|
|
|
|
|
* @port_ka_time: time of next port keep-alive.
|
|
|
|
|
* @ctlr_ka_time: time of next controller keep-alive.
|
|
|
|
|
* @timer: timer struct used for all delayed events.
|
2010-03-13 00:08:23 +00:00
|
|
|
* @timer_work: &work_struct for doing keep-alives and resets.
|
2009-11-03 19:47:45 +00:00
|
|
|
* @recv_work: &work_struct for receiving FIP frames.
|
2009-03-17 18:42:40 +00:00
|
|
|
* @fip_recv_list: list of received FIP frames.
|
2010-12-01 00:19:56 +00:00
|
|
|
* @flogi_req: clone of FLOGI request sent
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
* @rnd_state: state for pseudo-random number generator.
|
|
|
|
|
* @port_id: proposed or selected local-port ID.
|
2009-11-03 19:47:45 +00:00
|
|
|
* @user_mfs: configured maximum FC frame size, including FC header.
|
|
|
|
|
* @flogi_oxid: exchange ID of most recent fabric login.
|
2010-12-01 00:19:56 +00:00
|
|
|
* @flogi_req_send: send of FLOGI requested
|
2009-11-03 19:47:45 +00:00
|
|
|
* @flogi_count: number of FLOGI attempts in AUTO mode.
|
|
|
|
|
* @map_dest: use the FC_MAP mode for destination MAC addresses.
|
2016-07-19 11:49:40 +00:00
|
|
|
* @fip_resp: start FIP VLAN discovery responder
|
2009-11-03 19:47:45 +00:00
|
|
|
* @spma: supports SPMA server-provided MACs mode
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
* @probe_tries: number of FC_IDs probed
|
2016-07-19 11:49:40 +00:00
|
|
|
* @priority: DCBx FCoE APP priority
|
2009-11-03 19:47:45 +00:00
|
|
|
* @dest_addr: MAC address of the selected FC forwarder.
|
|
|
|
|
* @ctl_src_addr: the native MAC address of our local port.
|
|
|
|
|
* @send: LLD-supplied function to handle sending FIP Ethernet frames
|
|
|
|
|
* @update_mac: LLD-supplied function to handle changes to MAC addresses.
|
|
|
|
|
* @get_src_addr: LLD-supplied function to supply a source MAC address.
|
2010-07-20 22:19:47 +00:00
|
|
|
* @ctlr_mutex: lock protecting this structure.
|
2010-12-01 00:19:56 +00:00
|
|
|
* @ctlr_lock: spinlock covering flogi_req
|
2009-03-17 18:42:40 +00:00
|
|
|
*
|
|
|
|
|
* This structure is used by all FCoE drivers. It contains information
|
|
|
|
|
* needed by all FCoE low-level drivers (LLDs) as well as internal state
|
|
|
|
|
* for FIP, and fields shared with the LLDS.
|
|
|
|
|
*/
|
|
|
|
|
struct fcoe_ctlr {
|
|
|
|
|
enum fip_state state;
|
2016-07-04 08:29:19 +00:00
|
|
|
enum fip_mode mode;
|
2009-03-17 18:42:40 +00:00
|
|
|
struct fc_lport *lp;
|
|
|
|
|
struct fcoe_fcf *sel_fcf;
|
|
|
|
|
struct list_head fcfs;
|
2013-09-05 07:47:27 +00:00
|
|
|
struct fcoe_ctlr_device *cdev;
|
2009-03-17 18:42:40 +00:00
|
|
|
u16 fcf_count;
|
|
|
|
|
unsigned long sol_time;
|
|
|
|
|
unsigned long sel_time;
|
|
|
|
|
unsigned long port_ka_time;
|
|
|
|
|
unsigned long ctlr_ka_time;
|
|
|
|
|
struct timer_list timer;
|
2010-03-13 00:08:23 +00:00
|
|
|
struct work_struct timer_work;
|
2009-03-17 18:42:40 +00:00
|
|
|
struct work_struct recv_work;
|
|
|
|
|
struct sk_buff_head fip_recv_list;
|
2010-12-01 00:19:56 +00:00
|
|
|
struct sk_buff *flogi_req;
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
|
|
|
|
|
struct rnd_state rnd_state;
|
|
|
|
|
u32 port_id;
|
|
|
|
|
|
2009-03-17 18:42:40 +00:00
|
|
|
u16 user_mfs;
|
|
|
|
|
u16 flogi_oxid;
|
2010-12-01 00:19:56 +00:00
|
|
|
u8 flogi_req_send;
|
2009-03-17 18:42:40 +00:00
|
|
|
u8 flogi_count;
|
2016-07-19 11:49:40 +00:00
|
|
|
bool map_dest;
|
|
|
|
|
bool fip_resp;
|
2009-05-17 12:33:28 +00:00
|
|
|
u8 spma;
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
u8 probe_tries;
|
2011-11-18 21:35:56 +00:00
|
|
|
u8 priority;
|
2009-03-17 18:42:40 +00:00
|
|
|
u8 dest_addr[ETH_ALEN];
|
|
|
|
|
u8 ctl_src_addr[ETH_ALEN];
|
|
|
|
|
|
|
|
|
|
void (*send)(struct fcoe_ctlr *, struct sk_buff *);
|
2009-11-03 19:46:29 +00:00
|
|
|
void (*update_mac)(struct fc_lport *, u8 *addr);
|
|
|
|
|
u8 * (*get_src_addr)(struct fc_lport *);
|
2010-07-20 22:19:47 +00:00
|
|
|
struct mutex ctlr_mutex;
|
2010-12-01 00:19:56 +00:00
|
|
|
spinlock_t ctlr_lock;
|
2009-03-17 18:42:40 +00:00
|
|
|
};
|
|
|
|
|
|
2012-05-23 02:06:10 +00:00
|
|
|
/**
|
|
|
|
|
* fcoe_ctlr_priv() - Return the private data from a fcoe_ctlr
|
2024-04-08 02:54:22 +00:00
|
|
|
* @ctlr: The fcoe_ctlr whose private data will be returned
|
|
|
|
|
*
|
|
|
|
|
* Returns: pointer to the private data
|
2012-05-23 02:06:10 +00:00
|
|
|
*/
|
|
|
|
|
static inline void *fcoe_ctlr_priv(const struct fcoe_ctlr *ctlr)
|
|
|
|
|
{
|
|
|
|
|
return (void *)(ctlr + 1);
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-05 07:47:27 +00:00
|
|
|
/*
|
|
|
|
|
* This assumes that the fcoe_ctlr (x) is allocated with the fcoe_ctlr_device.
|
|
|
|
|
*/
|
2012-05-23 02:06:26 +00:00
|
|
|
#define fcoe_ctlr_to_ctlr_dev(x) \
|
2013-09-05 07:47:27 +00:00
|
|
|
(x)->cdev
|
2012-05-23 02:06:26 +00:00
|
|
|
|
2009-11-03 19:47:45 +00:00
|
|
|
/**
|
|
|
|
|
* struct fcoe_fcf - Fibre-Channel Forwarder
|
|
|
|
|
* @list: list linkage
|
2012-05-23 02:06:26 +00:00
|
|
|
* @event_work: Work for FC Transport actions queue
|
|
|
|
|
* @fip: The controller that the FCF was discovered on
|
|
|
|
|
* @fcf_dev: The associated fcoe_fcf_device instance
|
2009-11-03 19:47:45 +00:00
|
|
|
* @time: system time (jiffies) when an advertisement was last received
|
|
|
|
|
* @switch_name: WWN of switch from advertisement
|
|
|
|
|
* @fabric_name: WWN of fabric from advertisement
|
|
|
|
|
* @fc_map: FC_MAP value from advertisement
|
2012-03-09 22:50:03 +00:00
|
|
|
* @fcf_mac: Ethernet address of the FCF for FIP traffic
|
|
|
|
|
* @fcoe_mac: Ethernet address of the FCF for FCoE traffic
|
2009-11-03 19:47:45 +00:00
|
|
|
* @vfid: virtual fabric ID
|
|
|
|
|
* @pri: selection priority, smaller values are better
|
2010-12-01 00:19:56 +00:00
|
|
|
* @flogi_sent: current FLOGI sent to this FCF
|
2009-11-03 19:47:45 +00:00
|
|
|
* @flags: flags received from advertisement
|
|
|
|
|
* @fka_period: keep-alive period, in jiffies
|
2024-04-08 02:54:22 +00:00
|
|
|
* @fd_flags: no need for FKA from ENode
|
2009-03-17 18:42:40 +00:00
|
|
|
*
|
|
|
|
|
* A Fibre-Channel Forwarder (FCF) is the entity on the Ethernet that
|
|
|
|
|
* passes FCoE frames on to an FC fabric. This structure represents
|
|
|
|
|
* one FCF from which advertisements have been received.
|
|
|
|
|
*
|
|
|
|
|
* When looking up an FCF, @switch_name, @fabric_name, @fc_map, @vfid, and
|
|
|
|
|
* @fcf_mac together form the lookup key.
|
|
|
|
|
*/
|
|
|
|
|
struct fcoe_fcf {
|
|
|
|
|
struct list_head list;
|
2012-05-23 02:06:26 +00:00
|
|
|
struct work_struct event_work;
|
|
|
|
|
struct fcoe_ctlr *fip;
|
|
|
|
|
struct fcoe_fcf_device *fcf_dev;
|
2009-03-17 18:42:40 +00:00
|
|
|
unsigned long time;
|
|
|
|
|
|
|
|
|
|
u64 switch_name;
|
|
|
|
|
u64 fabric_name;
|
|
|
|
|
u32 fc_map;
|
|
|
|
|
u16 vfid;
|
|
|
|
|
u8 fcf_mac[ETH_ALEN];
|
2012-03-09 22:50:03 +00:00
|
|
|
u8 fcoe_mac[ETH_ALEN];
|
2009-03-17 18:42:40 +00:00
|
|
|
|
|
|
|
|
u8 pri;
|
2010-12-01 00:19:56 +00:00
|
|
|
u8 flogi_sent;
|
2009-03-17 18:42:40 +00:00
|
|
|
u16 flags;
|
|
|
|
|
u32 fka_period;
|
2009-11-20 22:54:57 +00:00
|
|
|
u8 fd_flags:1;
|
2009-03-17 18:42:40 +00:00
|
|
|
};
|
|
|
|
|
|
2012-05-23 02:06:26 +00:00
|
|
|
#define fcoe_fcf_to_fcf_dev(x) \
|
|
|
|
|
((x)->fcf_dev)
|
|
|
|
|
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
/**
|
|
|
|
|
* struct fcoe_rport - VN2VN remote port
|
2024-04-08 02:54:22 +00:00
|
|
|
* @rdata: libfc remote port private data
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
* @time: time of create or last beacon packet received from node
|
|
|
|
|
* @fcoe_len: max FCoE frame size, not including VLAN or Ethernet headers
|
|
|
|
|
* @flags: flags from probe or claim
|
|
|
|
|
* @login_count: number of unsuccessful rport logins to this port
|
|
|
|
|
* @enode_mac: E_Node control MAC address
|
|
|
|
|
* @vn_mac: VN_Node assigned MAC address for data
|
|
|
|
|
*/
|
|
|
|
|
struct fcoe_rport {
|
2019-07-24 09:00:55 +00:00
|
|
|
struct fc_rport_priv rdata;
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
unsigned long time;
|
|
|
|
|
u16 fcoe_len;
|
|
|
|
|
u16 flags;
|
|
|
|
|
u8 login_count;
|
|
|
|
|
u8 enode_mac[ETH_ALEN];
|
|
|
|
|
u8 vn_mac[ETH_ALEN];
|
|
|
|
|
};
|
|
|
|
|
|
2009-03-17 18:42:40 +00:00
|
|
|
/* FIP API functions */
|
2019-02-15 12:19:20 +00:00
|
|
|
void fcoe_ctlr_init(struct fcoe_ctlr *, enum fip_mode);
|
2009-03-17 18:42:40 +00:00
|
|
|
void fcoe_ctlr_destroy(struct fcoe_ctlr *);
|
|
|
|
|
void fcoe_ctlr_link_up(struct fcoe_ctlr *);
|
|
|
|
|
int fcoe_ctlr_link_down(struct fcoe_ctlr *);
|
2009-11-03 19:46:29 +00:00
|
|
|
int fcoe_ctlr_els_send(struct fcoe_ctlr *, struct fc_lport *, struct sk_buff *);
|
2009-03-17 18:42:40 +00:00
|
|
|
void fcoe_ctlr_recv(struct fcoe_ctlr *, struct sk_buff *);
|
2009-11-03 19:47:45 +00:00
|
|
|
int fcoe_ctlr_recv_flogi(struct fcoe_ctlr *, struct fc_lport *,
|
2009-11-03 19:49:16 +00:00
|
|
|
struct fc_frame *);
|
2009-03-17 18:42:40 +00:00
|
|
|
|
2008-12-09 23:10:24 +00:00
|
|
|
/* libfcoe funcs */
|
scsi: fcoe: Fix Wstringop-overflow warnings in fcoe_wwn_from_mac()
Fix the following Wstringop-overflow warnings when building with GCC-11:
drivers/scsi/fcoe/fcoe.c: In function ‘fcoe_netdev_config’:
drivers/scsi/fcoe/fcoe.c:744:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=]
744 | wwnn = fcoe_wwn_from_mac(ctlr->ctl_src_addr, 1, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/fcoe/fcoe.c:744:32: note: referencing argument 1 of type ‘unsigned char *’
In file included from drivers/scsi/fcoe/fcoe.c:36:
./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’
252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int);
| ^~~~~~~~~~~~~~~~~
drivers/scsi/fcoe/fcoe.c:747:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=]
747 | wwpn = fcoe_wwn_from_mac(ctlr->ctl_src_addr,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
748 | 2, 0);
| ~~~~~
drivers/scsi/fcoe/fcoe.c:747:32: note: referencing argument 1 of type ‘unsigned char *’
In file included from drivers/scsi/fcoe/fcoe.c:36:
./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’
252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int);
| ^~~~~~~~~~~~~~~~~
CC drivers/scsi/bnx2fc/bnx2fc_io.o
In function ‘bnx2fc_net_config’,
inlined from ‘bnx2fc_if_create’ at drivers/scsi/bnx2fc/bnx2fc_fcoe.c:1543:7:
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:833:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=]
833 | wwnn = fcoe_wwn_from_mac(ctlr->ctl_src_addr,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
834 | 1, 0);
| ~~~~~
drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function ‘bnx2fc_if_create’:
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:833:32: note: referencing argument 1 of type ‘unsigned char *’
In file included from drivers/scsi/bnx2fc/bnx2fc.h:53,
from drivers/scsi/bnx2fc/bnx2fc_fcoe.c:17:
./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’
252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int);
| ^~~~~~~~~~~~~~~~~
In function ‘bnx2fc_net_config’,
inlined from ‘bnx2fc_if_create’ at drivers/scsi/bnx2fc/bnx2fc_fcoe.c:1543:7:
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:839:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=]
839 | wwpn = fcoe_wwn_from_mac(ctlr->ctl_src_addr,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
840 | 2, 0);
| ~~~~~
drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function ‘bnx2fc_if_create’:
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:839:32: note: referencing argument 1 of type ‘unsigned char *’
In file included from drivers/scsi/bnx2fc/bnx2fc.h:53,
from drivers/scsi/bnx2fc/bnx2fc_fcoe.c:17:
./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’
252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int);
| ^~~~~~~~~~~~~~~~~
drivers/scsi/qedf/qedf_main.c: In function ‘__qedf_probe’:
drivers/scsi/qedf/qedf_main.c:3520:30: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=]
3520 | qedf->wwnn = fcoe_wwn_from_mac(qedf->mac, 1, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/qedf/qedf_main.c:3520:30: note: referencing argument 1 of type ‘unsigned char *’
In file included from drivers/scsi/qedf/qedf.h:9,
from drivers/scsi/qedf/qedf_main.c:23:
./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’
252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int);
| ^~~~~~~~~~~~~~~~~
drivers/scsi/qedf/qedf_main.c:3521:30: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=]
3521 | qedf->wwpn = fcoe_wwn_from_mac(qedf->mac, 2, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/qedf/qedf_main.c:3521:30: note: referencing argument 1 of type ‘unsigned char *’
In file included from drivers/scsi/qedf/qedf.h:9,
from drivers/scsi/qedf/qedf_main.c:23:
./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’
252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int);
| ^~~~~~~~~~~~~~~~~
by changing the array size to the correct value of ETH_ALEN in the
argument declaration.
Also, fix a couple of checkpatch warnings:
WARNING: function definition argument 'unsigned int' should also have an identifier name
This helps with the ongoing efforts to globally enable
-Wstringop-overflow.
Link: https://github.com/KSPP/linux/issues/181
Fixes: 85b4aa4926a5 ("[SCSI] fcoe: Fibre Channel over Ethernet")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2022-03-03 23:55:21 +00:00
|
|
|
u64 fcoe_wwn_from_mac(unsigned char mac[ETH_ALEN], unsigned int scheme,
|
|
|
|
|
unsigned int port);
|
[SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support
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 <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-20 22:20:30 +00:00
|
|
|
int fcoe_libfc_config(struct fc_lport *, struct fcoe_ctlr *,
|
|
|
|
|
const struct libfc_function_template *, int init_fcp);
|
2011-01-29 00:05:37 +00:00
|
|
|
u32 fcoe_fc_crc(struct fc_frame *fp);
|
|
|
|
|
int fcoe_start_io(struct sk_buff *skb);
|
2011-08-05 00:38:49 +00:00
|
|
|
int fcoe_get_wwn(struct net_device *netdev, u64 *wwn, int type);
|
2011-10-03 23:45:01 +00:00
|
|
|
void __fcoe_get_lesb(struct fc_lport *lport, struct fc_els_lesb *fc_lesb,
|
|
|
|
|
struct net_device *netdev);
|
2011-08-05 00:38:49 +00:00
|
|
|
void fcoe_wwn_to_str(u64 wwn, char *buf, int len);
|
|
|
|
|
int fcoe_validate_vport_create(struct fc_vport *vport);
|
2012-12-06 06:23:58 +00:00
|
|
|
int fcoe_link_speed_update(struct fc_lport *);
|
2012-12-06 06:24:13 +00:00
|
|
|
void fcoe_get_lesb(struct fc_lport *, struct fc_els_lesb *);
|
|
|
|
|
void fcoe_ctlr_get_lesb(struct fcoe_ctlr_device *ctlr_dev);
|
2009-03-17 18:42:24 +00:00
|
|
|
|
2010-07-20 22:19:32 +00:00
|
|
|
/**
|
2024-04-08 02:54:22 +00:00
|
|
|
* is_fip_mode() - test if FIP mode selected.
|
2010-07-20 22:19:32 +00:00
|
|
|
* @fip: FCoE controller.
|
2024-04-08 02:54:22 +00:00
|
|
|
*
|
|
|
|
|
* Returns: %true if FIP mode is selected
|
2010-07-20 22:19:32 +00:00
|
|
|
*/
|
|
|
|
|
static inline bool is_fip_mode(struct fcoe_ctlr *fip)
|
|
|
|
|
{
|
|
|
|
|
return fip->state == FIP_ST_ENABLED;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-29 00:04:50 +00:00
|
|
|
/* helper for FCoE SW HBA drivers, can include subven and subdev if needed. The
|
|
|
|
|
* modpost would use pci_device_id table to auto-generate formatted module alias
|
|
|
|
|
* into the corresponding .mod.c file, but there may or may not be a pci device
|
|
|
|
|
* id table for FCoE drivers so we use the following helper for build the fcoe
|
|
|
|
|
* driver module alias.
|
|
|
|
|
*/
|
|
|
|
|
#define MODULE_ALIAS_FCOE_PCI(ven, dev) \
|
|
|
|
|
MODULE_ALIAS("fcoe-pci:" \
|
|
|
|
|
"v" __stringify(ven) \
|
|
|
|
|
"d" __stringify(dev) "sv*sd*bc*sc*i*")
|
|
|
|
|
|
|
|
|
|
/* the name of the default FCoE transport driver fcoe.ko */
|
|
|
|
|
#define FCOE_TRANSPORT_DEFAULT "fcoe"
|
|
|
|
|
|
|
|
|
|
/* struct fcoe_transport - The FCoE transport interface
|
|
|
|
|
* @name: a vendor specific name for their FCoE transport driver
|
|
|
|
|
* @attached: whether this transport is already attached
|
|
|
|
|
* @list: list linkage to all attached transports
|
|
|
|
|
* @match: handler to allow the transport driver to match up a given netdev
|
2012-11-27 06:53:30 +00:00
|
|
|
* @alloc: handler to allocate per-instance FCoE structures
|
|
|
|
|
* (no discovery or login)
|
2011-01-29 00:04:50 +00:00
|
|
|
* @create: handler to sysfs entry of create for FCoE instances
|
2012-11-27 06:53:30 +00:00
|
|
|
* @destroy: handler to delete per-instance FCoE structures
|
|
|
|
|
* (frees all memory)
|
2011-01-29 00:04:50 +00:00
|
|
|
* @enable: handler to sysfs entry of enable for FCoE instances
|
|
|
|
|
* @disable: handler to sysfs entry of disable for FCoE instances
|
|
|
|
|
*/
|
|
|
|
|
struct fcoe_transport {
|
|
|
|
|
char name[IFNAMSIZ];
|
|
|
|
|
bool attached;
|
|
|
|
|
struct list_head list;
|
|
|
|
|
bool (*match) (struct net_device *device);
|
2012-11-27 06:53:30 +00:00
|
|
|
int (*alloc) (struct net_device *device);
|
2016-07-04 08:29:19 +00:00
|
|
|
int (*create) (struct net_device *device, enum fip_mode fip_mode);
|
2011-01-29 00:04:50 +00:00
|
|
|
int (*destroy) (struct net_device *device);
|
|
|
|
|
int (*enable) (struct net_device *device);
|
|
|
|
|
int (*disable) (struct net_device *device);
|
|
|
|
|
};
|
|
|
|
|
|
2011-01-29 00:05:37 +00:00
|
|
|
/**
|
|
|
|
|
* struct fcoe_percpu_s - The context for FCoE receive thread(s)
|
2016-04-12 15:16:54 +00:00
|
|
|
* @kthread: The thread context (used by bnx2fc)
|
|
|
|
|
* @work: The work item (used by fcoe)
|
2011-01-29 00:05:37 +00:00
|
|
|
* @fcoe_rx_list: The queue of pending packets to process
|
2024-04-08 02:54:22 +00:00
|
|
|
* @crc_eof_page: The memory page for calculating frame trailer CRCs
|
2011-01-29 00:05:37 +00:00
|
|
|
* @crc_eof_offset: The offset into the CRC page pointing to available
|
|
|
|
|
* memory for a new trailer
|
2024-04-08 02:54:22 +00:00
|
|
|
* @lock: local lock for members of this struct
|
2011-01-29 00:05:37 +00:00
|
|
|
*/
|
|
|
|
|
struct fcoe_percpu_s {
|
2016-04-12 15:16:54 +00:00
|
|
|
struct task_struct *kthread;
|
|
|
|
|
struct work_struct work;
|
2011-01-29 00:05:37 +00:00
|
|
|
struct sk_buff_head fcoe_rx_list;
|
|
|
|
|
struct page *crc_eof_page;
|
|
|
|
|
int crc_eof_offset;
|
2022-05-06 10:57:55 +00:00
|
|
|
local_lock_t lock;
|
2011-01-29 00:05:37 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* struct fcoe_port - The FCoE private structure
|
|
|
|
|
* @priv: The associated fcoe interface. The structure is
|
|
|
|
|
* defined by the low level driver
|
|
|
|
|
* @lport: The associated local port
|
|
|
|
|
* @fcoe_pending_queue: The pending Rx queue of skbs
|
|
|
|
|
* @fcoe_pending_queue_active: Indicates if the pending queue is active
|
|
|
|
|
* @max_queue_depth: Max queue depth of pending queue
|
|
|
|
|
* @min_queue_depth: Min queue depth of pending queue
|
|
|
|
|
* @timer: The queue timer
|
|
|
|
|
* @destroy_work: Handle for work context
|
|
|
|
|
* (to prevent RTNL deadlocks)
|
2024-04-08 02:54:22 +00:00
|
|
|
* @data_src_addr: Source address for data
|
|
|
|
|
* @get_netdev: function that returns a &net_device from @lport
|
2011-01-29 00:05:37 +00:00
|
|
|
*
|
|
|
|
|
* An instance of this structure is to be allocated along with the
|
|
|
|
|
* Scsi_Host and libfc fc_lport structures.
|
|
|
|
|
*/
|
|
|
|
|
struct fcoe_port {
|
|
|
|
|
void *priv;
|
|
|
|
|
struct fc_lport *lport;
|
|
|
|
|
struct sk_buff_head fcoe_pending_queue;
|
|
|
|
|
u8 fcoe_pending_queue_active;
|
|
|
|
|
u32 max_queue_depth;
|
|
|
|
|
u32 min_queue_depth;
|
|
|
|
|
struct timer_list timer;
|
|
|
|
|
struct work_struct destroy_work;
|
|
|
|
|
u8 data_src_addr[ETH_ALEN];
|
fcoe: prep work to start consolidate the usage of fcoe_netdev
Currently, in the default kernel fcoe driver, it is needed to get to the underlying
private per fcoe transport's private structure, e.g., fcoe_interface in
fcoe.ko, and returns the associated netdev. The similar logic exists in other
fcoe drivers, e.g., bnx2fc, so we add a function pointer into the common
fcoe_port struct to allow individual fcoe transport implementaion (fcoe
and bnx2fc) to get the corresponding netdev associated with a give lport.
Then a inline fcoe_get_netdev() is added as part of libfcoe for all underlying
fcoe transport drivers to use regardless of its individual fcoe transport
driver, and also allows move more common code such as fcoe_link_speed_update or
fcoe_ctlr_get_lesb to be in libfcoe, rather than specific to fcoe.
This patch is a prep work that adds aforementioned fucntion pointer, and
followed by the actual code changes to make use of it.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
2012-12-06 06:23:27 +00:00
|
|
|
struct net_device * (*get_netdev)(const struct fc_lport *lport);
|
2011-01-29 00:05:37 +00:00
|
|
|
};
|
2012-12-06 06:23:43 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* fcoe_get_netdev() - Return the net device associated with a local port
|
|
|
|
|
* @lport: The local port to get the net device from
|
2024-04-08 02:54:22 +00:00
|
|
|
*
|
|
|
|
|
* Returns: the &net_device associated with this @lport
|
2012-12-06 06:23:43 +00:00
|
|
|
*/
|
|
|
|
|
static inline struct net_device *fcoe_get_netdev(const struct fc_lport *lport)
|
|
|
|
|
{
|
|
|
|
|
struct fcoe_port *port = ((struct fcoe_port *)lport_priv(lport));
|
|
|
|
|
|
|
|
|
|
return (port->get_netdev) ? port->get_netdev(lport) : NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-29 00:05:37 +00:00
|
|
|
void fcoe_clean_pending_queue(struct fc_lport *);
|
|
|
|
|
void fcoe_check_wait_queue(struct fc_lport *lport, struct sk_buff *skb);
|
2017-09-21 20:12:15 +00:00
|
|
|
void fcoe_queue_timer(struct timer_list *t);
|
2011-01-29 00:05:37 +00:00
|
|
|
int fcoe_get_paged_crc_eof(struct sk_buff *skb, int tlen,
|
|
|
|
|
struct fcoe_percpu_s *fps);
|
|
|
|
|
|
2012-05-23 02:06:26 +00:00
|
|
|
/* FCoE Sysfs helpers */
|
|
|
|
|
void fcoe_fcf_get_selected(struct fcoe_fcf_device *);
|
2012-11-27 06:53:30 +00:00
|
|
|
void fcoe_ctlr_set_fip_mode(struct fcoe_ctlr_device *);
|
2012-05-23 02:06:26 +00:00
|
|
|
|
2011-01-29 00:04:50 +00:00
|
|
|
/**
|
2024-04-08 02:54:22 +00:00
|
|
|
* struct fcoe_netdev_mapping - A mapping from &net_device to &fcoe_transport
|
|
|
|
|
* @list: list linkage of the mappings
|
|
|
|
|
* @netdev: the &net_device
|
|
|
|
|
* @ft: the fcoe_transport associated with @netdev
|
2011-01-29 00:04:50 +00:00
|
|
|
*/
|
|
|
|
|
struct fcoe_netdev_mapping {
|
|
|
|
|
struct list_head list;
|
|
|
|
|
struct net_device *netdev;
|
|
|
|
|
struct fcoe_transport *ft;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* fcoe transports registration and deregistration */
|
|
|
|
|
int fcoe_transport_attach(struct fcoe_transport *ft);
|
|
|
|
|
int fcoe_transport_detach(struct fcoe_transport *ft);
|
2010-07-20 22:19:32 +00:00
|
|
|
|
2012-11-27 06:53:30 +00:00
|
|
|
/* sysfs store handler for ctrl_control interface */
|
2023-03-13 18:29:05 +00:00
|
|
|
ssize_t fcoe_ctlr_create_store(const char *buf, size_t count);
|
|
|
|
|
ssize_t fcoe_ctlr_destroy_store(const char *buf, size_t count);
|
2012-11-27 06:53:30 +00:00
|
|
|
|
2008-12-09 23:10:24 +00:00
|
|
|
#endif /* _LIBFCOE_H */
|
2012-11-27 06:53:30 +00:00
|
|
|
|
|
|
|
|
|
