public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
To: Ira Weiny <weiny2-i2BcT+NCU+M@public.gmane.org>
Cc: "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH V2] libibumad: update umad_recv man page.
Date: Fri, 06 Jul 2012 15:32:51 -0400	[thread overview]
Message-ID: <4FF73D63.9010704@dev.mellanox.co.il> (raw)
In-Reply-To: <20120706122408.2540ea8dd74f94dcadd3fce1-i2BcT+NCU+M@public.gmane.org>

On 7/6/2012 3:24 PM, Ira Weiny wrote:
> On Fri, 06 Jul 2012 14:34:24 -0400
> Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
> 
>> On 7/3/2012 12:55 PM, Ira Weiny wrote:
>>>
>>> Document the umad_recv length parameter better.
>>>
>>> Changes since V1:
>>> 	add comments from Hal
>>>
>>> Signed-off-by: Ira Weiny <weiny2-i2BcT+NCU+M@public.gmane.org>
>>> ---
>>>  man/umad_recv.3 |   18 +++++++++++++++++-
>>>  1 files changed, 17 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/man/umad_recv.3 b/man/umad_recv.3
>>> index e1b2985..310d3d2 100644
>>> --- a/man/umad_recv.3
>>> +++ b/man/umad_recv.3
>>> @@ -27,10 +27,26 @@ A negative
>>>  makes the function block until a packet is received. A
>>>  .I timeout_ms\fR
>>>  parameter of zero indicates a non blocking read.
>>> +
>>> +.B Note
>>> +.I length
>>> +is a pointer to the length of the
>>> +.B data
>>> +portion of the umad buffer.  This means that
>>> +.I umad
>>> +should point to a buffer at least umad_size() +
>>> +.I *length
>>> +bytes long.
>>> +
>>> +.B Note also
>>> +that
>>> +.I *length\fR
>>> +must be >= 256 bytes.
>>
>> This seems somewhat redundant to me as just above it says "should point
>> to a bugger that's at least umad_size() + *length bytes long.
>>
>> Also, if this remains, should "must be" be "should be" ?
> 
> I _guess_ it _could_ be less than 256.  

My only point here is that if it's less than 256 + header, then the
error is returned (and nothing useful can be done). To me, that makes it
a should rather than a must but just make the two lines consistent.
Roland does have this as a must in user_mad.txt kernel doc:
"The buffer passed to read() must be at least one struct ib_user_mad +
256 bytes."

-- Hal

> However the specification states:
> 
> 	"C13-3: The data payload (as used in Chapter 9: Transport Layer on page 233) for all MADs shall be exactly 256 bytes."
> 
> Furthermore, the kernel checks to ensure that *length is > the first (or only) packet in the MAD transaction.  While some Class/Attributes may allow for less "valid" data I'm not sure the kernel distinguishes that.  Therefore, I think it is safer to just specify it.  Don't you think?

> Ira
> 
>>
>>> +
>>>  .SH "RETURN VALUE"
>>>  .B umad_recv()
>>>  returns non negative receiving agentid on success, and a negative value on error as follows:
>>> - -EINVAL      invalid port handle or agentid
>>> + -EINVAL      invalid port handle or agentid or *length is less than the minimum
>>
>> Rather than just minimum, minimum support length might be clearer.
>>
>> -- Hal
>>
>>>   -EIO         receive operation failed
>>>   -EWOULDBLOCK non blocking read can't be fulfilled
>>>  .SH "SEE ALSO"
>>
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2012-07-06 19:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-03 16:55 [PATCH V2] libibumad: update umad_recv man page Ira Weiny
     [not found] ` <20120703095522.1e89cd25.weiny2-i2BcT+NCU+M@public.gmane.org>
2012-07-06 18:34   ` Hal Rosenstock
     [not found]     ` <4FF72FB0.6020202-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2012-07-06 19:24       ` Ira Weiny
     [not found]         ` <20120706122408.2540ea8dd74f94dcadd3fce1-i2BcT+NCU+M@public.gmane.org>
2012-07-06 19:32           ` Hal Rosenstock [this message]
     [not found]             ` <4FF73D63.9010704-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2012-07-06 19:38               ` Ira Weiny
     [not found]                 ` <20120706123804.d3d836b998988a2cc5be0ca5-i2BcT+NCU+M@public.gmane.org>
2012-07-06 19:41                   ` Hal Rosenstock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FF73D63.9010704@dev.mellanox.co.il \
    --to=hal-ldsdmyg8hgv8yrgs2mwiifqbs+8scbdb@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=weiny2-i2BcT+NCU+M@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox