Currently fcoe_ddp_min doesn't have default value
so by default not used, so setting up default value
as 4k as this works better by avoiding overhead
of programing DDP for small IOs.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Use real dev in case it has HW vlan acceleration
support since in this case the real dev would
do needed vlan processing, this way unnecessary
vlan layer processing avoided and it gives
slightly better IOPS with 512B size IOs.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Since fcoe_percpu_thread_create() creates percpu kthread, it makes sense
to use kthread_create_on_node() to get proper NUMA affinity for kthread
stack.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Export fcoe_get_wwn, fcoe_validate_vport_create and fcoe_wwn_to_str so that all
LLDs can use these common function.
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Cleanup to:

- have selection for all types of frames, not just FCP.
- remove redundant cpu_online check once fcoe_select_cpu called
  as this is not required since later code flow check for offlined
  cpu.
- Simplify fcoe_select_cpu() by removing unnecessary checks to
  skip curr_cpu, this also fixes possibly infinite loop in case
  of curr_cpu is the only cpu while iterating in the loop.

This cleanup mainly applies to target as incoming request are
mostly for target, therefore Kiran has verified the patch
with target also.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NKiran Patil <kiran.patil@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Use pending queue to retry FIP frame in case its tx
fails and use common pending queue for both fcoe
and fip frames using fcoe_port_send.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Drop the rx frame having xid with wrong cpu info
or received with xid  not matching to our xid.

Not dropping such frame is causing panic as
that causes accessing data struct beyond their
bounds.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

There is no need to cache the ptype in fcoe_rcv_info struct as it is never
used anywhere.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

When NPIV port destroy handler is called it does not do all the cleanup
required for the given NPIV port. This was happening as some of the
lport cleanup moved to fcoe_interface_cleanup() routine, which is not
called as part of the vport delete process.

This patch rearranges the sequence in which the fcoe_if_destory() and
fcoe_interface_cleanup() functions are being called from various places
in the code. It now matches the sequence they are constructed during the
create process for both N_Port as well as NPIV port.
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NNeerav Parikh <Neerav.Parikh@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

[SCSI] fcoe: Amends previous patch, Round-robin based selection of CPU for post processing of incoming request for FCoE target

Problem: Selection of RX queue on target is based on RX-ID. FCoE used
8 Net Rx queues.  HW post the packets based on rx_id %
num_rx_queue. Due to this has based filtering, only one CPU is busy
servicing incoming request including post-processing of incoming
request. This is gating factor because

1. Only one CPU is utilized 100% while others CPUs are not used at all.

2. CPU which received request assign "sequence' by selecting exchange
   from per CPU pool (num_ddp_context / num_online_cpus,
   approxi.). Due to which if if rate of incoming request is higher
   than rate of servicing request, existing code path end of sending
   "BUSY" response (SAM_STAT_BUSY because unable to allocate
   exchange).

Fix: Fan-out incoming request to all other CPUs excluding the CPU
which is receiving all incoiming request. This path also addresses,
selecting same CPU based on rx_id from received frame for completion
of the request such as "releasing exchange to the per CPU Pool". This
fix is applicable for FCoE target since initiator code path already
takes care of selecting CPU to complete post-processing of request
once OX_ID is assigned.

Notes: N/A

Dependencines: N/A
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Problem: Earlier mechanism of selection of CPU was, to select the same CPU
which has received incoming request. Hence in case of rx_id = 0xFFFF,
request was always posted to same NetRx queue, hence only 1 CPU is utilized
for handling the command. It was also causing problem of "running out of
exchanges from per CPU pool of exchanges (in case of DDP offload)

Fix: Implemented new algo. to select CPU for post-processing of
incoming commands when rx_id is unknown. This is simple Round robin
algo. for CPU selection.

Notes/Dependencies: N/A
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Problem: When initiator sends write command to target, target tries to
assign new sequence. It allocates new exchangeID (RX_ID)
always from non-offloaded pool (Non-offload EMA)

Fix: Enhanced fcoe_oem_match routine to look at F_CTL flags and if it
is exchange responder and command type is WRITEDATA, then function
returns TRUE instead of FALSE. This function is used to determine
which pool to use (offload pool of exchange is used only if this
function returns TRUE).

Technical Notes: N/A
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Add ddp_target() support to the Open-FCoE sw fcoe hba driver (fcoe.ko).
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This patch adds a validation step before allowing creation of a new NPIV port.
It checks whether the WWPN passed for the new NPIV port to be created is unique
for the given physical port.
Signed-off-by: NNeerav Parikh <Neerav.Parikh@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <jbottomley@parallels.com>

Currently fcoe interface cleanup is done after ndo_fcoe_disable
and that prevents logoff going out to the peer, so this patch
moves all netdev cleanup and its releasing inside
fcoe_interface_cleanup to have log off before ndo_fcoe_disable
disables the fcoe.

This patch also fixes asymmetric rtnl locking around fcoe_if_destroy,
as currently this function requires rtnl held by its caller
and then have this func drops the lock, instead now don't have
any processing under rtnl inside fcoe_if_destroy, this required
moving few func to get build working again.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

The check of module state being MODULE_STATE_LIVE is no longer needed for the
individual fcoe transport driver, e.g., fcoe.ko, as sysfs entries now go to
libfcoe now, if it reaches fcoe.ko, it has to be already registered. The module
state check for libfcoe will guard the possible race condition of sysfs being
writable before module_init function is called and after module_exit.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

These checks were initially added to avoid a lockdep
false positive when dealing with the s_active, rtnl
and fcoe_config_mutex mutexes. Recently the create,
destroy, enable and disable sysfs entries were moved
from fcoe.ko to libfcoe.ko. With this change the mutex
usage was shuffled around and the lockdep false
positive stopped happening. We can now remove these
checks.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

This makes sure that when a driver calls the ethtool's
get/set_settings() callback of another driver, the data passed to it
is clean. This guarantees that speed_hi will be zeroed correctly if
the called callback doesn't explicitely set it: we are sure we don't
get a corrupted speed from the underlying driver. We also take care of
setting the cmd field appropriately (ETHTOOL_GSET/SSET).

This applies to dev_ethtool_get_settings(), which now makes sure it
sets up that ethtool command parameter correctly before passing it to
drivers. This also means that whoever calls dev_ethtool_get_settings()
does not have to clean the ethtool command parameter. This function
also becomes an exported symbol instead of an inline.

All drivers visible to make allyesconfig under x86_64 have been
updated.
Signed-off-by: NDavid Decotigny <decot@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Check for bonding master and refuse to use that.
Signed-off-by: NJiri Pirko <jpirko@redhat.com>
Acked-by: NRobert Love <robert.w.love@intel.com>
Acked-by: NJames Bottomley <James.Bottomley@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reset using "fcoeadm -r" also needs to restart FIP before
doing libfc lport reset, this is needed for new switch firmware
requiring FIP solicitation before doing FLOGI again during reset.
So this patch does this by doing fcoe_ctlr_link_down and then
fcoe_ctlr_link_up to reset the interface.

The fcoe_ctlr_link_down call path also does lport reset
and then fcoe_ctlr_link_up re-starts the fabric login after
doing FIP solicitation first to get reset feature working
again.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Negate has higher precedence than bitwise AND.  FCPHF_CRC_UNCHECKED is
0x1 so the original code is equivalent to: if (!fr_flags(fp)) { ...
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

EM anchors list initialization for only master port was not enough to
keep npiv working as described here:-
https://lists.open-fcoe.org/pipermail/devel/2011-January/011063.html

So this patch moves fc_exch_mgr_list_clone to update npiv ports
EMs once EM anchors list initialized.

Also some cleanup, no need to set lport = NULL as that always
get initialized later.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

fcoe uses the system_wq to destroy ports and the work items need to be
flushed before the driver is unloaded.  As the work items free the
containing data structure, they can't be flushed directly.  The
workqueue should be flushed instead.

Also, the destruction works can be chained - ie. destruction of a port
may lead to destruction of another port where the work item for the
former queues the work for the latter.  Currently, the depth of chain
can be at most two and fcoe_exit() makes sure everything is complete
by calling flush_scheduled_work() twice.

With commit c8efcc25 (workqueue: allow chained queueing during
destruction), destroy_workqueue() can take care of chained works on
workqueue destruction.  Add and use fcoe_wq instead.  Simply
destroying fcoe_wq on driver unload takes care of flushing.
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Remove the existing sysfs entry points of the fcoe.ko module parameters that
are used to create/destroy/enable/disable an FCoE instance, rather, use the
newly added fcoe transport code to attach itself as an FCoE transport provider
when fcoe.ko gets loaded. There is no functionality change on the logic of
fcoe interacts with upper libfc and lower netdev. The fcoe transport only acts
as thin layer to provide a unified interface for all fcoe transport providers
so all FCoE instances on any network interfaces from all vendors can be
managed through the same Open-FCoE.org's user space tool package, which also
has full DCB support.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Prepare the fcoe to convert it to use the newly added fcoe transport, making
it as the default fcoe transport provider for libfcoe. This patch is to rename
some of the variables to avoid any confusing names later as now there are
several transports in the same file.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Allowing FCoE LOGO followed by CVL in this case prevents
FIP login back to the FCF and then keeps lport offline,
only FIP LOGO and CLV needs to be processed while in
FIP mode, therefore this patch drops FCoE LOGO in FIP mode.

Added fcoe_filter_frames() to filter out above mentioned LOGO
in fcoe rx path along with other existing filtering in code
for bad CRC frames. Adding separate fcoe_filter_frames function
helped with better code indentations and if needed then same
will allow adding more filters at one place in future.

This LOGO drop is added after FCP frames passed up to avoid
any additional checks on fast path for this.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

vports are not grabbing module references but are
releasing them. This causes the module reference count
to decrement too many times and it wraps around past 0.

The solution is to do a module_put() in
fcoe_interface_release() so that the reference is only
released when the fcoe_interface is released. There is a
one-to-one relationship between the N_Port and the
fcoe_interface, so the module reference will only be
dropped when the N_Port is destroyed

To create symetry in the code this patch moves the
try_module_get() call into fcoe_interface_create(). This
means that only the N_Port will grab a reference to the
module when its corresponding fcoe_interface is created.

This patch also makes it so that the fcoe_interface_create()
routine encodes any error codes in the fcoe_interface
pointer returned. This way its caller, fcoe_create(), can
return an accurate error code.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

This happens when then tearing down the fcoe interface with active I/O.
The back trace shows dead000000200200 in RAX, i.e., LIST_POISON2, indicating
that the fsp is already being dequeued, which is probably why no complaining
was seen in fc_fcp_destroy() about outstanding fsp not freed, since we dequeue
it in the end of fc_io_compl() before releasing it. The bug is due to the
fact that we have already destroyed lport's scsi_pkt_pool while on-going i/o
is still accessing it through fc_fcp_pkt_release(), like this trace or the
similar code path from scsi-ml to fc_eh_abort, etc. This is fixed by moving
the fc_fcp_destroy() after lport is detached from scsi-ml since fc_fcp_destroy
is supposed to called only once where no lport lock is taken, otherwise the
fc_fcp_pkt_release() would have to grab the lport lock.

 BUG: unable to handle kernel NULL pointer dereference at (null)
 .......
 RIP: 0010:[<0000000000000000>]
 [<(null)>] (null)
 RSP: 0018:ffff8803270f7b88  EFLAGS: 00010282
 RAX: dead000000200200 RBX: ffff880197d2fbc0 RCX: 0000000000005908
 RDX: ffff880195ea6d08 RSI: 0000000000000282 RDI: ffff880180f4fec0
 RBP: ffff8803270f7bc0 R08: ffff880197d2fbe0 R09: 0000000000000000
 R10: ffff88032867f090 R11: 0000000000000000 R12: ffff880195ea6d08
 R13: 0000000000000282 R14: ffff880180f4fec0 R15: 0000000000000000
 FS:  0000000000000000(0000) GS:ffff8801b5820000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
 CR2: 0000000000000000 CR3: 00000001a6eae000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process fc_rport_eq (pid: 5278, threadinfo ffff8803270f6000, task ffff880326254ab0)
 Stack:
 ffffffffa02c39ca ffff8803270f7ba0 ffff88019331cbc0 ffff880197d2fbc0
 0000000000000000 ffff8801a8c895e0 ffff8801a8c895e0 ffff8803270f7c10
 ffffffffa02c4962 ffff8803270f7be0 ffffffff814c94ab ffff8803270f7c10
 Call Trace:
 [<ffffffffa02c39ca>] ? fc_io_compl+0x10a/0x530 [libfc]
 [<ffffffffa02c4962>] fc_fcp_complete_locked+0x72/0x150 [libfc]
 [<ffffffff814c94ab>] ? _spin_unlock_bh+0x1b/0x20
 [<ffffffffa02b98ff>] ? fc_exch_done+0x3f/0x60 [libfc]
 [<ffffffffa02c4a8f>] fc_fcp_retry_cmd+0x4f/0x60 [libfc]
 [<ffffffffa02c6150>] fc_fcp_recv+0x9b0/0xc30 [libfc]
 [<ffffffff8106ba7a>] ? _call_console_drivers+0x4a/0x80
 [<ffffffff8107d5ec>] ? lock_timer_base+0x3c/0x70
 [<ffffffff8107e06b>] ? try_to_del_timer_sync+0x7b/0xe0
 [<ffffffffa02b9dcf>] fc_exch_mgr_reset+0x1df/0x250 [libfc]
 [<ffffffffa02c57a0>] ? fc_fcp_recv+0x0/0xc30 [libfc]
 [<ffffffffa02c1042>] fc_rport_work+0xf2/0x4e0 [libfc]
 [<ffffffff8109203e>] ? prepare_to_wait+0x4e/0x80
 [<ffffffffa02c0f50>] ? fc_rport_work+0x0/0x4e0 [libfc]
 [<ffffffff8108c6c0>] worker_thread+0x170/0x2a0
 [<ffffffff81091d50>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff8108c550>] ? worker_thread+0x0/0x2a0
 [<ffffffff810919e6>] kthread+0x96/0xa0
 [<ffffffff810141ca>] child_rip+0xa/0x20
 [<ffffffff81091950>] ? kthread+0x0/0xa0
 [<ffffffff810141c0>] ? child_rip+0x0/0x20
 Code:
 Bad RIP value.

 RIP
 [<(null)>] (null)
 RSP <ffff8803270f7b88>
 CR2: 0000000000000000
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

A previous patch attempted to validate the destination
MAC address of a FCoE frame by checking that MAC
address against the received port's MAC address. The
implementation seems fine on the surface, but any
VN_Ports added using the NPIV feature will have their
own MAC addresses and these MACs were not being checked,
which prevented any NPIV VN_Ports from receiving frames.

In other words, the following patch has broken NPIV.

519e5135
 [SCSI] fcoe: adds src and dest mac address
              checking for fcoe frames

Part of the offending patch is correct, but the part
that broke NPIV was attempting to satisfy FC-BB-5
section D.5, 2.1-

(discard frames that) "contain a destination MAC
address/destination N_Port_ID pair that was not
assigned by an FCF to one of the VN_Ports on the ENode"

The language does _not_ say to compare the destination
FC-MAP/destination N_Port_ID, but instead to compare
the destination MAC address/destination N_Port_ID.

>From the FC-BB-5 specification,

"A properly formed FPMA is one in which the 24 most
significant bits equal the Fabric’s FC-MAP value and
the least significant 24 bits equal the N_Port_ID
assigned to the VN_Port by the FCF."

This means that we need to compare the FC Frame's
destination FCID against the embedded FCID in the
destination MAC address. This patch checks the lower
24 bits of the destination MAC address against
destination FCID in the Fibre Channel frame.

For MAC validation the first line of defense is the
hardware MAC filtering. Each VN_Port will have a
unicast MAC addresses added to the hardware's
filtering table. The Ethernet driver should drop any
MACs not destined for a programmed MAC. This patch
adds a second line of defense that very specfically
compares an element in the FC frame against an element
in the Ethernet header, which is appropriate for the
FCoE layer.

Many alternative approaches were considered, including
a LLD callback from libfc. The second most reasonable
approach seemed to be walking the list of NPIV ports
and check each of their MAC addresses against the
destination MAC address of the received frame. The
problem with this approach was that it is likely that
performance would suffer with the more NPIV ports added
to the system since every received frame would need to
walk this list, comparing each entry's MAC.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Since sometimes current FIP_MODE_AUTO mode falls back to non-FIP
mode while DCB link still getting ready in fabric mode with
its peer switch, it falls back after few libfc flogi retries
and that is not we want while working with FIP enabled
switches in FABRIC mode, therefore sets default as FIP_MODE_FABRIC
as discussed and agreed before in this mail thread
http://www.open-fcoe.org/pipermail/devel/2010-August/010511.htmlSigned-off-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

This reverts commit cc0136c2.

That commit introduced vlan id info to WWPN but WWPN needs to
remain static as an unique port identifier in the fabric, therefore
variable fabric vlan id info doesn't need to be coded inside WWPN.

After this revert, port arg to fcoe_wwn_from_mac is always zero
but still leaving it as-is okay to later allow users to use NAA 2
scheme with this additional port arg.

Note with this patch, existing zoning using WWPN would require
re-zoning this time only and later no more re-zoning due to any
vlan id changes.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Currently, when FCoE netdev feature flags are toggled by the LLD, lport's
corresponding flags are not updated. This causes the fc_fcp to still try to
offload the I/O. This patch adds support of NETDEV_FEAT_CHANGE event in fcoe
netdev device notification callback so we can update the lport offload flags
appropriately.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Add module parameter create_vn2vn that behaves like the create
parameter except that the new instance is created in FIP vn2vn mode.

This can be replaced once we change create to allow modifying
per-instance attributes before starting the instance.
Signed-off-by: NJoe Eykholt <jeykholt@cisco.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

In VN2VN mode, map_dest means to use the default VN2VN OUI.
Change code that uses the default FCoE OUI to use the one
set in the fcoe_ctlr struct.
Signed-off-by: NJoe Eykholt <jeykholt@cisco.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NJoe Eykholt <jeykholt@cisco.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NJoe Eykholt <jeykholt@cisco.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

The fc_fabric_logoff and fc_fabric_login are redundant
here after recently added fcoe_ctlr_link_down/up to
these functions, therefore this patch removes logoff
and login to only use link down and up here. This works
best for their current usages with fcoe DCB link down or up.

This also works well to avoid EIO errors when fcoe DCB link
goes down as lport state moves out of ready quickly from
fcoe_ctlr_link_down and that allows re-queuing timed out IOs
for this case also.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

There is a small possibility that a reader gets incorrect values on 32
bit arches. SNMP applications could catch incorrect counters when a
32bit high part is changed by another stats consumer/provider.

One way to solve this is to add a rtnl_link_stats64 param to all
ndo_get_stats64() methods, and also add such a parameter to
dev_get_stats().

Rule is that we are not allowed to use dev->stats64 as a temporary
storage for 64bit stats, but a caller provided area (usually on stack)

Old drivers (only providing get_stats() method) need no changes.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>