Thanks James for the fix. -Hiral On 2/22/13 10:09 AM, "James Bottomley" <jbottomley@xxxxxxxxxxxxx> wrote: >On Tue, 2013-02-12 at 17:01 -0800, Hiral Patel wrote: >> FIP VLAN discovery discovers the FCoE VLAN that will be used by all >>other FIP protocols >> as well as by the FCoE encapsulation for Fibre Channel payloads on the >>established >> virtual link. One of the goals of FC-BB-5 was to be as nonintrusive as >>possible on >> initiators and targets, and therefore FIP VLAN discovery occurs in the >>native VLAN >> used by the initiator or target to exchange Ethernet traffic. The FIP >>VLAN discovery >> protocol is the only FIP protocol running on the native VLAN; all other >>FIP protocols >> run on the discovered FCoE VLANs. >> >> If an administrator has manually configured FCoE VLANs on ENodes and >>FCFs, there is no need >> to use this protocol. FIP and FCoE will run over the configured VLANs. >> >> An ENode without FCoE VLANs configuration would use this automated >>discovery protocol to >> discover over which VLANs FCoE is running. >> >> The ENode sends a FIP VLAN discovery request to a multicast MAC address >>called All-FCF-MACs, >> which is a multicast MAC address to which all FCFs listen. >> >> All FCFs that can be reached in the native VLAN of the ENode are >>expected to respond on the >> same VLAN with a response that lists one or more FCoE VLANs that are >>available for the ENode's >> VN_Port login. This protocol has the sole purpose of allowing the ENode >>to discover all the >> available FCoE VLANs. >> >> Now the ENode may enable a subset of these VLANs for FCoE Running the >>FIP protocol in these >> VLANs on a per VLAN basis. And FCoE data transactions also would occur >>on this VLAN. Hence, >> Except for FIP VLAN discovery, all other FIP and FCoE traffic runs on >>the selected FCoE VLAN. >> Its only the FIP VLAN Discovery protocol that is permitted to run on >>the Default native VLAN >> of the system. >> >> [**** NOTE ****] >> We are working on moving this feature definitions and functionality to >>libfcoe module. We need >> this patch to be approved, as Suse is looking forward to merge this >>feature in SLES 11 SP3 release. >> Once this patch is approved, we will submit patch which should move >>vlan discovery feature to libfoce. >> >> Signed-off-by: Anantha Prakash T <atungara@xxxxxxxxx> >> Signed-off-by: Hiral Patel <hiralpat@xxxxxxxxx> > >This is still rejecting: > >jejb@dabdike> patch -p1 < .git/rebase-apply/patch >patching file drivers/scsi/fnic/fnic.h >patching file drivers/scsi/fnic/fnic_fcs.c >patching file drivers/scsi/fnic/fnic_fip.h >patching file drivers/scsi/fnic/fnic_main.c >Hunk #3 FAILED at 411. >Hunk #4 succeeded at 628 (offset -1 lines). >Hunk #5 succeeded at 837 (offset -1 lines). >Hunk #6 succeeded at 926 (offset -1 lines). >Hunk #7 succeeded at 988 (offset -1 lines). >1 out of 7 hunks FAILED -- saving rejects to file >drivers/scsi/fnic/fnic_main.c.rej > >The rejection is because of the __devinit removal patch that went into >the 3.8 merge window. This definitely means you're not building with >the misc branch of the scsi tree, which is based on 3.8-rc6. > >I fixed it up because we were making no progress otherwise. > >James > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
