Chris Leech wrote:
> On Wed, May 20, 2009 at 06:28:22PM -0700, Joe Eykholt wrote:
>> Chris Leech wrote:
>>> The following series add NPIV support for libfc/libfcoe/fcoe.
>
>>> 2) Receive demux is still a problem. NPIV breaks the 1:1 association of
>>> N_Port to network device. That means that we can't just use the protocol
>>> handlers to get directly to an fc_lport structure. I don't like the way
>>> these
>>> patches currently handle it, potentially walking the vport list for every
>>> received frame. Handling the FLOGI and FDISC responses is an added
>>> difficulty here, because the can't be matched by fabric ID.
>> 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.
>
> I like the shared EM approach as well, but am struggling with changing
> the receive path to not need lport matching. Most of the time it works
> to indicate a received frame and an EM to find the exchange in, but
> there's still the case of a new request that we need to respond to.
> There we need to match the lport by the D_ID.
I guess that's needed. It could be a quick hash lookup. Usually the D_IDs
for an NPIV port will be the same except for the least-significant bits.
It could be a very fast lookup. It isn't that critical since it's used
only on new incoming requests and we aren't optimizing for targets yet.
> I'd like to delay the ID lookup until it's know that we'll need it, in
> fc_exch_recv_req(), but that requires a way to match D_ID given only the
> EM.
That sounds OK. The first lookup is needed to find the lport for
lport->tt.lport_recv(), I think. Until then, the lport isn't used.
So, maybe the exchange manager needs a lookup function that finds
the right lport for the D_ID out of all the lports that share it.
That function would default to something simple (just return fr_dev()),
so non-shared exchange manager code (fnic) doesn't change. An additional
call could set the lookup function after allocating a shared EM.
> Also, all this means that the fr_dev pointer will not be set or will not
> always be the correct lport. It's being used in one place,
> fc_exch_send_ba_rjt().
Sounds like that lookup function should be called to get fr_dev() set
correctly by or before that.
Regards,
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
