On Wed, 2006-03-22 at 18:10 -0800, Sean Hefty wrote:
> This is fairly abstract, so please let me know if my understanding or logic is
> off anywhere.
>
> Do we really have two conceptual contexts here? One that tracks the user's
> information and another that interacts with the provider?
>
> The
This is fairly abstract, so please let me know if my understanding or logic is
off anywhere.
Do we really have two conceptual contexts here? One that tracks the user's
information and another that interacts with the provider?
The user context is created / destroyed by calls to iw_create_cm_id()
On Wed, 2006-03-22 at 15:51 -0800, Sean Hefty wrote:
> >The user, being the IWCM, will always see a CONNECT_REPLY to a connect
> >downcall.
>
> I understand that a CONNECT_REPLY event is generated in response to calling
> connect(). But can any events (e.g. CLOSE) follow that without the user
>
On Wed, 2006-03-22 at 16:35 -0800, Sean Hefty wrote:
> >> Tom, can you post more info on the various events and their relationship
> >> to the cm_id states? Maybe that will help?
> >[] around a string represent client calls
> ><> around a string represent provider events
>
> Thanks - just to be c
>> Tom, can you post more info on the various events and their relationship
>> to the cm_id states? Maybe that will help?
>[] around a string represent client calls
><> around a string represent provider events
Thanks - just to be clear, my concern is that neither a client nor the iwcm try
to acc
[EMAIL PROTECTED] wrote:
>> The user, being the IWCM, will always see a CONNECT_REPLY to a
>> connect downcall.
>
> I understand that a CONNECT_REPLY event is generated in
> response to calling connect(). But can any events (e.g.
> CLOSE) follow that without the user taking any other action?
>
>
>The user, being the IWCM, will always see a CONNECT_REPLY to a connect
>downcall.
I understand that a CONNECT_REPLY event is generated in response to calling
connect(). But can any events (e.g. CLOSE) follow that without the user taking
any other action?
>> How are
>> additional events that are
On Wed, 2006-03-22 at 13:09 -0800, Caitlin Bestler wrote:
> [EMAIL PROTECTED] wrote:
> >>> For example, as soon as the user calls connect(), can they receive a
> >>> CLOSE event, even before the connect() call returns?
> >>
> >> No. connect results in a CONNECT_REPLY event always. Not a CLOSE
> >
[EMAIL PROTECTED] wrote:
>>> For example, as soon as the user calls connect(), can they receive a
>>> CLOSE event, even before the connect() call returns?
>>
>> No. connect results in a CONNECT_REPLY event always. Not a CLOSE
>> event.
>
> What if the remote side sends the reply, then decides to
On Wed, 2006-03-22 at 11:40 -0800, Sean Hefty wrote:
> >> For example, as soon as the user calls connect(), can they receive a CLOSE
> >> event, even before the connect() call returns?
> >
> >No. connect results in a CONNECT_REPLY event always. Not a CLOSE
> >event.
>
> What if the remote side se
>> For example, as soon as the user calls connect(), can they receive a CLOSE
>> event, even before the connect() call returns?
>
>No. connect results in a CONNECT_REPLY event always. Not a CLOSE
>event.
What if the remote side sends the reply, then decides to abort or disconnect?
I'm considering
On Wed, 2006-03-22 at 10:28 -0800, Sean Hefty wrote:
> >Once the the cm_id is connected, the provider must post a CLOSE event
> >when it is done with the cm_id. That's the model. The IWCM will not
> >free the cm_id until the CLOSE upcall happens. Adding an explicit
> >alloc_context/dealloc_cont
>Once the the cm_id is connected, the provider must post a CLOSE event
>when it is done with the cm_id. That's the model. The IWCM will not
>free the cm_id until the CLOSE upcall happens. Adding an explicit
>alloc_context/dealloc_context in the provider will just push this logic
>down into each
| What's needed is a simple way to know that a provider will not invoke
a callback
| referencing an invalid context. This code tries to push this
responsibility to
| the owner of the context (i.e. here), rather than down into the
provider, where
| it really belongs.
|
| Somewhere the provider i
On Thu, 2006-03-16 at 13:16 -0800, Sean Hefty wrote:
> >The bottom line requirement is that state transitions are
> >atomic. As long as you know that at most one entity transitions
> >the QP out of the Established state everything should work.
>
> I'll buy this. My comments and questions are just
On Thu, 2006-03-16 at 13:16 -0800, Sean Hefty wrote:
> >The bottom line requirement is that state transitions are
> >atomic. As long as you know that at most one entity transitions
> >the QP out of the Established state everything should work.
>
> I'll buy this. My comments and questions are just
>The bottom line requirement is that state transitions are
>atomic. As long as you know that at most one entity transitions
>the QP out of the Established state everything should work.
I'll buy this. My comments and questions are just trying to make sure that I
understand everything that's happen
> It's confusing trying to figure out who's responsible for QP transitions. In
> some places, the iw_cm performs the transitions. In others, the provider is
> expected to have performed them. Is there a way to make this consistent, so
> that all QP transitions are initiated from the same loc
Sean Hefty wrote:
> Tom Tucker wrote:
>
>> +cm_id_priv->id.state = IW_CM_STATE_ESTABLISHED;
>> +} else
>> +cm_id_priv->id.state = IW_CM_STATE_IDLE;
>> +
>> +spin_unlock_irqrestore(&cm_id_priv->lock, flags); +
>> +/* Call the client CM handler */
>> +return
On Thu, 2006-03-16 at 09:12 -0800, Sean Hefty wrote:
> Tom Tucker wrote:
> > The iWARP CM prevents this from happening by having a state (DESTROYING)
> > that prevents events from being delivered after iw_destroy_cm_id has
> > returned. This approach avoids having either the kernel application
> >
[EMAIL PROTECTED] wrote:
> Tom Tucker wrote:
>> The iWARP CM prevents this from happening by having a state
>> (DESTROYING) that prevents events from being delivered after
>> iw_destroy_cm_id has returned. This approach avoids having either the
>> kernel application thread or the event thread block
Tom Tucker wrote:
The iWARP CM prevents this from happening by having a state (DESTROYING)
that prevents events from being delivered after iw_destroy_cm_id has
returned. This approach avoids having either the kernel application
thread or the event thread blocked while waiting for the last referen
On Thu, 2006-03-16 at 00:39 -0800, Sean Hefty wrote:
> >On Wed, 2006-03-15 at 16:34 -0800, Sean Hefty wrote:
> >> Tom Tucker wrote:
> >> > +static inline void iwcm_deref_id(struct iwcm_id_private *cm_id_priv)
> >> > +{
> >> > +if (atomic_dec_and_test(&cm_id_priv->refcount))
> >> > +
>On Wed, 2006-03-15 at 16:34 -0800, Sean Hefty wrote:
>> Tom Tucker wrote:
>> > +static inline void iwcm_deref_id(struct iwcm_id_private *cm_id_priv)
>> > +{
>> > + if (atomic_dec_and_test(&cm_id_priv->refcount))
>> > + kfree(cm_id_priv);
>> > +}
>>
>> I'm wary of code that does this. Th
24 matches
Mail list logo
