Process Associators revisited

[Jeff Stai]

* From the T10 Reflector (t10 at t10.org), posted by:
* Jeff Stai <j_stai at qlc.com>
*

hi Charles,

good point - my comments are embedded...

> -----Original Message-----
> From: Binford, Charles [mailto:charles.binford at lsil.com]

> Bob,  I agree with the general direction you are heading.  
> However, I have a
> question about the mechanics of how the multiple ID's get assigned.
> Specifically, when the N(L)_Port logs into the fabric the second or
> subsequent time with a different WWN, how is the fabric to 
> differentiate
> between the following two cases:
> 
> 1) port is a "multi-ID port" and wants another ID
> 
> 2) the user merely swapped cables and this is a new port
>    (note:  hubs in the path could isolate the FL_Port from 
> seeing a "link
> down" event while the user swaps cables.)

yup - we would need to handle fabric logouts very carefully!!

> 
> Also, it seems there needs to be an upper limit on the number of IDs a
> single port can obtain.  I don't make switches, but if I did 
> I'd certainly
> want to know how to allocate the IDs up front.

Gee - if I were a host adapter who is supposed to support
multiple IDs, I'd like to know MY upper limit too!-)

Based on the Domain/Area/Port ID model, we do have
an upper limit. For any Domain, there are approximately
64000 available ID values (65536 minus reserved etc.).
In theory anyway...

This is something I have chewed on for a while, because
our Domain/Area/Port model naturally limits any switch
to 256 multi-function ports (i.e., ports that can be
F_Ports, FL_Ports, or E_Ports). Here's why:

1) The upper 8-bits of any port is fixed to the
Domain_ID.

2) Each FL_Port has its lower 8-bits fixed to the
AL_PA of the attached loop devices.

3) The only part of the ID that the switch 
can control is the middle 8-bits - 256 ports.

Given this natural limit on switch ports, we can
see what works... (scroll down a bit)
> 
> It was not discussed directly, but I assume a requirement for 
> a port wanting
> to provide this functionality on a loop would be for it to 
> acquire multiple
> IDs in the appropriate LIP phase.  For example, a port may 
> come up, LIP, and
> grab an address during the LIHA phase.  Later, when the 
> driver instructs it
> to obtain its second ID the port LIPs again, grabs the 
> original ID in the
> LIPA phase, and the second ID in the LISA phase.  Am I on 
> track with how you
> see this working Bob?

In fact, we don't have to do anything to enable this
today. I am familiar with devices that already know
how to do this...

If we agree to the following, we get our natural
limit to the number of ports per physical port:

1) NL_Ports get multiple IDs by acquiring
multiple AL_PAs within their local loop; i.e. NL_Ports
get multiple IDs that are always of the form ddaaPP,
where ddaa is fixed, and PP is an AL_PA. The NL_Port
then does FLOGI for each AL_PA.

2) N_Ports get multiple IDs via FLOGIs, as described
by Bob. We have to control logouts very carefully
as noted by Charles to avoid ambiguities. The IDs for
N_Ports are also of the form ddaaPP, but in this case
the switch assigns PP according to its own implementation.

In both cases, the natural limit ends up being at most 256,
and perhaps as low as 126, depending on which constraint
we choose.

NOTE: The only way we can therefore exceed this natural
limit is by taking loops completely out of the picture!

All of this sounds cool, but we still haven't heard
how many IDs would be -needed- per physical port: 5?
50? 500?

Process associators allowed for 2^32 processes.

This scheme would appear to offer only 2^8.

But will that be enough for the unforeseeable future?

</ramble>

thanks for reading! - js

jeff stai, QLogic corp.
3545 harbor blvd, costa mesa, ca 92626
714-668-5425vm, 714-668-5095fx
j_stai at qlc.com  http://www.qlc.com/



> 
> 
> 
> Charles Binford
> LSI Logic Storage Systems
> (316) 636-8566
> 
> 
> -----Original Message-----
> From: Bob Snively [mailto:Bob.Snively at EBay.Sun.COM]
> Sent: Tuesday, November 30, 1999 1:24 PM
> To: fc at network.com; t10 at t10.org
> Subject: Process Associators revisited
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Bob Snively <Bob.Snively at EBay.Sun.COM>
> *
> 
> To:		NCITS T10 members, NCITS T11 members
> 
> From:		Bob Snively
> 
> Subject:	Process Associators revisited
> 
> [text deleted]
> 
> To create an alternate image for a single port, the port needs only to
> perform a new login with an additional world-wide name.  
> After that, it
> behaves exactly like any normal port and can perform the complete
> FC-2 management functions and the FCP-2 initiator and/or target
> functionality
> just like any port, totally independent of other address 
> identifiers that
> may be defined for the same port.  This meets the desired technical
> goals.
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org