Chris Leech wrote:
> On Wed, May 20, 2009 at 06:28:22PM -0700, Joe Eykholt wrote:
>
>> For FIP, there should be just one handler for all the lports on the fabric.
>> Most of the FIP frames are for the main lport and its link state. Link
>> state of course affects all the lports.
>>
>> The demux for FLOGI/FDISC responses should be in libfcoe. That'll
>> work better for fnic, which also needs to do the same thing.
>
> I had some thoughts related to this. I think we can use the elsct_send
> hook in libfcoe to handle FIP encapsulated ELS and take those checks out
> of the SCSI FCP transmit fast path. It also makes it easier to share
> between fcoe and fnic.
OK, that sounds like a minor change. I don't see any improvement to sharing.
I will probably send my fnic FIP patches out for comment soon. Only a tiny
change to common code.
> The receive side isn't as critical, as they're already filtered out by the
> FIP ethertype, but it might be cleaner to use an FCoE specific exchange
> response handler to do the address handling for FLOGI and FDISC.
>
> I'll see what I can come up with.
One problem I noticed with the patch is that the fcoe_ctlr struct has the
flogi_xid in it, and now you need to keep track of fdisc_xids as well.
So maybe what you're suggesting will help that.
>> For FCoE, I think we need to key on the exchange ID, using a shared exchange
>> manager for all the NPIV sessions, or perhaps hash on the D_ID, but I prefer
>> the shared EM approach.
>
> That would be fairly easy, as long as there's not a concern of over
> sharing the X_ID space. It's probably OK, there shouldn't be an
> expectation of the number of outstanding exchanges scaling with NPIV.
It seems OK to me since all those X_IDs are using the same physical port.
Otherwise if multiple VNports have FDISC outstanding, they could use the
same X_IDs and it may not be possible to demux.
>> I'm really happy to see these patches. I haven't gone all the way through
>> them yet.
>> I'll have more comments tomorrow or so.
>
> Thanks Joe.
>
> Chris
Another thing, I didn't see any code to find out whether the switch is NPIV
capable.
There's a bit that comes back in the FLOGI LS_ACC that says it is. However, I
suppose
for management purposes, we want to create vports even if the link is down and
we don't know what the switch is at that point.
The bit is bit 29 in the common service parameters
features word (sp_features, same as FC_SP_FT_VAL). We could issue FDISC anyway,
but it might be nicer to remember that bit in the main lport and check it before
trying to send FDISC for the VNports.
Another thing. FIP needs to keep track of the link for the main lport only,
so that's whats in the fcoe_ctlr struct. Fine. But the other lports are going
to want to see the link events, too. Is there code for that? Would
fc_linkup()/linkdown()
just go through the list, or should fcoe_ctlr() do that.
How does the sending of FDISCs get delayed until after the FLOGI succeeds?
Thanks,
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
