On Thu, Oct 14, 2010 at 11:20 AM, Hefty, Sean <sean.he...@intel.com> wrote:
>> > Export the mad snooping capability to user space clients
>> > through the existing umad interface. This will allow
>> > users to capture MAD data for debugging, plus it allows
>> > for services to act on MAD traffic that occurs.
>>
>> Should it also be noted that snooping of RMPP'd MADs occurs at the
>> reassembled packet level with the last header being indicated ?
>
> I thought that the mad layer ending up reporting snooped MADs before
> reassembly and after segmentation. It's been a while since I've used madeye,
> but that's what I remember. I guess I'll find out during testing and make
> whatever adjustments are necessary,
Yes, you're right; I recall this now.
> but I agree that this should be documented.
>
> On a side note, while writing up this patch, it looks like madeye handles the
> data portion of sent RMPP MADs incorrectly. It doesn't reference the data
> portion (beyond the RMPP/MAD headers) correctly. See the snoop_send_handler
> for how I think this needs to be handled.
>
>> > diff --git a/include/rdma/ib_user_mad.h b/include/rdma/ib_user_mad.h
>> > index d6fce1c..0c40861 100644
>> > --- a/include/rdma/ib_user_mad.h
>> > +++ b/include/rdma/ib_user_mad.h
>> > @@ -165,10 +165,36 @@ struct ib_user_mad {
>> > typedef unsigned long __attribute__((aligned(4))) packed_ulong;
>> > #define IB_USER_MAD_LONGS_PER_METHOD_MASK (128 / (8 * sizeof (long)))
>> >
>> > +enum {
>> > + IB_UMAD_QP0,
>> > + IB_UMAD_QP1,
>> > + IB_UMAD_SNOOP = 0x80,
>> > + IB_UMAD_SNOOP_QP0 = IB_UMAD_SNOOP & IB_UMAD_QP0,
>> > + IB_UMAD_SNOOP_QP1 = IB_UMAD_SNOOP & IB_UMAD_QP1
>> > +};
>>
>> typos above: s.b. | r.t. &
>
> yep - thanks
>
>> > + * @qpn - Queue pair number; must be 0 or 1. If the upper bit of the
>> qpn
>> > + * is set to 1, then the registration will be set to snoop traffic
>> > + * over that QP.
>>
>> Should this take half the qpn space or be two specific values ?
>
> Two specific values is probably better. Note that the umad interface
> specifies the qpn using 8-bits, so we're definitely limited on the qpns that
> we could ever support. I know there's been discussion about possibly adding
> more reserved QPs, so I'm not sure what the best two values to reserve would
> be.
Me neither. Maybe the top two values ?
-- Hal
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
