[ewg] Application layer support for RMPP using OFED stack.

[Anton Bodner]

Hello -

 

I'm from QLogic Corp, and I'm trying to port some older applications to
OFED, using the OFED stack and the OFED umad api (specifically - opening
the /dev/infiniband/umadX, and using read / write).  I am using OFED
1.2.5.

 

My old application interrogates the SA, and also implements the RMPP in
the application layer.  In porting this application to OFED, I realize
that the OFED stack has the capability to do the RMPP on my behalf, but
that has an adverse effect on my application since my infiniband
interface in my app transfers 256 byte packets ONLY.  

 

Hence - I want my app to do the RMPP, not OFED.

 

So - I disabled RMPP support in OFED stack by registering with RMPP
version of 0.  This seems effective in stopping OFED stack from doing
the RMPP for me.   However - when I try to send the RMPP ack, it fails
at the write ().

 

I investigated the OFED stack code, and its failing in
ib_create_send_mad (drivers/infiniband/core/mad.c).  Investigation shows
that if one registered with RMPP version 0, then the 'send' never allows
rmpp to be active...  (code snippet below)

            if ((!mad_agent->rmpp_version &&

                 (rmpp_active || message_size > sizeof(struct ib_mad)))
||

                (!rmpp_active && message_size > sizeof(struct ib_mad)))

    {

                        return ERR_PTR(-EINVAL);

    }

 

My questions are these:

1. Has anyone tried an application layer supported RMPP ? If so - how
did you get past this logic (possible OFED bug??)

 

2. Is the OFED implementation intent to disable RMPP support COMPLETELY
when registering with a RMPP version of  0? If so, then how does one
implement a user level RMPP using the OFED stack?  Perhaps no one is
doing this at all since the stack already does it for you?

 

Like I said - the only reason I'm doing this is to port an old/ existing
app to OFED, and there is a considerable level of difficulty to rip our
app level RMPP support.  But perhaps this is the alternative I must
do...

 

Thanks

 

Anton Bodner

 

 Anton Bodner Jr.

QLogic Corporation

(610)233-4856

anton.bodner at qlogic.com

http://www.qlogic.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20071205/264c349d/attachment.html>