Leech, Christopher wrote:
> Mike Christie wrote:
>> Dev, Vasu wrote:
>>>> -----Original Message-----
>>>> From: Mike Christie [mailto:[EMAIL PROTECTED]
>>>> Sent: Wednesday, August 27, 2008 2:17 PM
>>>> To: Dev, Vasu
>>>> Cc: [email protected]
>>>> Subject: Re: [Open-FCoE] [PATCH 3/4] libfc: Added exch release
>>>> fc_exch_mgr_delete_ep()
>>>>
>>>> Dev, Vasu wrote:
>>>>>> -----Original Message-----
>>>>>> From: Mike Christie [mailto:[EMAIL PROTECTED]
>>>>>>
>>>>>> Ok so now I am really lost :) See the attached patch. It looks
>>>>>> like if fc_seq_lookup_recip returns FC_RJT_NONE then from the
>>>>>> fc_exch_find call it returns from fc_seq_lookup_recip with a hold
>>>>>> on the ep.
>>>>> Correct, the ep returned from fc_seq_lookup_recip() will have one
>>>>> exch hold and that will be used by upper layer as explained below
>>>>> in detail.
>>>>>
>>>>>> So in
>>>>>> fc_exch_recv_req we need to just release it?
>>>>> The exch hold from fc_seq_lookup_recip() will be released by upper
>>>>> layer response handler by calling fc_exch_done() but since
>>>>> fc_exch_done()
>>> will
>>>> But shouldn't there be a hold from when the ep was allocated and
>>>> added to the mp->exches array?
>>> Yes and I was looking at that case only when fc_exch_resp() allocates
>>> new exchange in fc_seq_lookup_recip() and that will be most likely
>>> cod
>> Ah I see. And I was only looking at the find paths :)
>
> Should fc_seq_lookup_recip be split into two functions? It does two
> distinctly different things; Lookup an exchange and return an error if
> it doesn't exist, or create an exchange returing an error if it already
> exists. And callers already need to know which one to expect in order
> to get the reference counting correct.
It could be simplified. It's only used internally, and only
called if SEQ_CTX is off. Why not expand it inline and then break up
fc_exch_recv_req() into two pieces, one for EX_CTX and one for !EX_CTX?
Possibly the two pieces will each be simpler.
The alternative is to hold the exchange even if an existing one is found.
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
