Joe Eykholt wrote: > Chris Leech wrote: >> From: Robert Love <[email protected]> >> >> FPMA indicates that the Fabric will provide the host's >> N_Port's MAC address. When sending a FLOGI/FDISC frame >> and FPMA was negotiated through FIP discovery we still >> need to provide the MAC descriptor, as per the >> specification, but the MAC should be zero'd out since >> the FCF will be providing it in the FLOGI/FDISC ACC. >> >> In FC-BB-5 section 7.8.7.4.2 (Fabric login) it states: >> >> The MAC address field in the MAC address descriptor of a FIP FLOGI >> Request operation or a FIP NPIV FDISC Request operation shall contain: >> a) the proposed MAC address to use as VN_Port MAC address if the ENode >> is requesting to use SPMA (see table 27); >> b) all zeroes to indicate no MAC address is proposed if the ENode is >> requesting to use FPMA (see table 27); or >> c) the proposed MAC address to use as VN_Port MAC address if the ENode >> supports both SPMA and FPMA and leaves the decision of which >> addressing scheme to use to the FCF (i.e., if both the FP and SP >> bits are set to one, see table 27).
I changed my (alleged) mind when I looked at this again. Case (c) is why we were setting the address if we have fip-spma set, whether the FCF has it or not. It leaves the decision up to the FCF. So, I think this patch is incorrect. We always support FPMA, so case (a) doesn't apply. >> >> This patch fixes case B. >> >> This patch also adds debug statements to illustrate >> whether a FPMA or SPMA MAC is added to a FLOGI/FDISC >> frame. >> >> Signed-off-by: Robert Love <[email protected]> >> Signed-off-by: Chris Leech <[email protected]> >> --- >> >> drivers/scsi/fcoe/libfcoe.c | 13 +++++++++++-- >> 1 files changed, 11 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/scsi/fcoe/libfcoe.c b/drivers/scsi/fcoe/libfcoe.c >> index 626edd6..348d84e 100644 >> --- a/drivers/scsi/fcoe/libfcoe.c >> +++ b/drivers/scsi/fcoe/libfcoe.c >> @@ -441,10 +441,19 @@ static int fcoe_ctlr_encaps(struct fcoe_ctlr *fip, >> struct fc_lport *lport, >> memset(mac, 0, sizeof(mac)); >> mac->fd_desc.fip_dtype = FIP_DT_MAC; >> mac->fd_desc.fip_dlen = sizeof(*mac) / FIP_BPW; >> - if (dtype != FIP_DT_FLOGI && dtype != FIP_DT_FDISC) >> + if (dtype != FIP_DT_FLOGI && dtype != FIP_DT_FDISC) { >> memcpy(mac->fd_mac, fip->get_src_addr(lport), ETH_ALEN); >> - else if (fip->spma) >> + } else if (fip_flags & FIP_FL_SPMA) { > > OK, that one-line change is the essential fix. > >> + LIBFCOE_FIP_DBG(fip, "FLOGI/FDISC sent with SPMA\n"); >> memcpy(mac->fd_mac, fip->ctl_src_addr, ETH_ALEN); >> + } else { >> + LIBFCOE_FIP_DBG(fip, "FLOGI/FDISC sent with FPMA\n"); >> + /* >> + * Some switches expect the MAC desc to have a 0 >> + * MAC if FPMA is negotiated. >> + */ >> + memset(mac->fd_mac, 0, ETH_ALEN); >> + } > > Note that the memset at line 441 already has zeroed the entire descriptor. > So, I don't think this additional memset is needed. > > Also note that SPMA is being obsoleted in T11 FC-BB-6. I don't > know what effect that has on this. I suppose it just means we > won't see SPMA flags from switches very much. I would > leave the FPMA debug message out. > >> skb->protocol = htons(ETH_P_FIP); >> skb_reset_mac_header(skb); >> > > Regards, > Joe > > > _______________________________________________ > devel mailing list > [email protected] > http://www.open-fcoe.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
