]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
libfc: Enhancement to RPORT state machine applicable only for VN2VN mode
authorKiran Patil <kiran.patil@intel.com>
Mon, 20 Jun 2011 23:58:59 +0000 (16:58 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 3 Oct 2011 18:40:48 +0000 (11:40 -0700)
commitcb9d94e8dc5b81e565ef4ecbc9a7f12be05414f8
treef994efaf5f2de58994761a7c8ea6ddd25a621f5b
parentf85eb4c9c9c9016da4e43d86f8fc29267798eab7
libfc: Enhancement to RPORT state machine applicable only for VN2VN mode

commit 480584818a4bb3655d8d0d875ed60b427fc61cc5 upstream.

Problem: Existing RPORT state machine continues witg FLOGI/PLOGI
process only after it receices beacon from other end. Once claiming
stage is over (either clain notify or clain repose), beacon is sent
and state machine enters into operational mode where it initiates the
rlogin process (FLOGI/PLOGI) to the peer but before this rlogin is
initiated, exitsing implementation checks if it received beacon from
other end, it beacon is not received yet, rlogin process is not
initiated. Other end initiates FLOGI but peer end keeps on rejecting
FLOGI, hence after 3 retries other end deletes associated rport, then
sends a beacon. Once the beacon is received, peer end now initiates
rlogin to the peer end but since associated rport is deleted FLOGI is
neither accepted nor the reject response send out because rport is
deleted. Hence unable to proceed withg FLOGI/PLOGI process and fails
to establish VN2VN connection.

Fix: VN2VN spec is not standard yet but based on exitsing collateral
on T11, it appears that, both end shall send beacon and enter into
'operational mode' without explictly waiting for beacon from other
end. Fix is to allow the RPORT login process as long as respective
RPORT is created (as part of claim notification / claim response) even
though state of RPORT is INIT. Means don't wait for beacon from peer
end, if peer end initiates FLOGI (means peer end exist and
responding).

Notes: This patch is preparing the FCoE stack for target wrt
offload. This is generic patch and harmless even if applied on storage
initiator because 'else if' condition of function 'fcoe_oem_found'
shall evaluate to TRUE only for targets.

Dependencies: None

Signed-off-by: Kiran Patil <kiran.patil@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/scsi/libfc/fc_rport.c