[openib-general] smpdump and current MAD layer

[Sean Hefty]

Hal Rosenstock wrote:

> On Tue, 2004-11-30 at 14:47, Sean Hefty wrote:
> 
>>I guess filtering can be done above the MAD layer, so just letting the 
>>user specify the qp_type may be all that's needed, beyond indicating 
>>that snooping is desired.  If we go this route, we can probably support 
>>any number of snoopers.
> 
> 
> Does that mean the snoopers would just be a list based on qp_type (and
> we have a list per QP type (SMI, GSI)) ?

This was my first thought...

Also, looking ahead at future changes that will be going into the code 
(RMPP, CM), plus a debugging issues that I'm hitting when loading the 
drivers, I think it makes sense to add in snooping sooner rather than 
later.

This is something that I can start, since it would be useful to me as a 
debugging tool today.

- Sean

To: Hal Rosenstock <halr at voltaire.com>
Subject: Re: [openib-general] smpdump and current MAD layer
References: <1101838548.6411.276.camel at localhost.localdomain>
In-Reply-To: <1101838548.6411.276.camel at localhost.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on openib.ca.sandia.gov
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
Cc: openib-general at openib.org
X-BeenThere: openib-general at openib.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OpenIB General Mailing List <openib-general.openib.org>
List-Unsubscribe: <http://openib.org/mailman/listinfo/openib-general>,
	<mailto:openib-general-request at openib.org?subject=unsubscribe>
List-Archive: <http://openib.org/pipermail/openib-general>
List-Post: <mailto:openib-general at openib.org>
List-Help: <mailto:openib-general-request at openib.org?subject=help>
List-Subscribe: <http://openib.org/mailman/listinfo/openib-general>,
	<mailto:openib-general-request at openib.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Dec 2004 18:04:13 -0000

Hal Rosenstock wrote:

> So solicited MAD responses cannot currently be snooped nor can
> unsolicited ones for which an agent is registered (Since SMA and PMA are
> currently firmware based, the latter is not an issue for the current
> implementation).

I've gotten a start on adding in the snooping support.  It was a little 
more difficult than I first thought to support multiple snoop clients, 
because of a race condition deregistering clients while snooping.

Question on where to perform the snoop callback on the send side: 
should it be done in the completion handling code, immediately before 
the MAD is posted to the QP, or somewhere else?

I'd like to place the snooping code in as few places as possible, but 
still be able to snoop locally processed MADs.  Ideally a MAD should be 
snooped exactly once, which requires some extra care when handling QP 
errors.  Snooping in the completion handling allows the MAD layer to 
own the thread that performs the callback.  Calling clients back on the 
outbound path puts the callback in an arbitrary thread context.

Thoughts?

- Sean