[Openib-windows] post_send/post_recv return values

[Yossi Leybovich]

> -----Original Message-----
> From: ftillier.sst at gmail.com [mailto:ftillier.sst at gmail.com] 
> On Behalf Of Fabian Tillier
> Sent: Monday, March 13, 2006 7:43 PM
> To: Yossi Leybovich
> Cc: openib-windows at openib.org; Ami Perlmutter
> Subject: Re: [Openib-windows] post_send/post_recv return values
> 
> On 3/13/06, Yossi Leybovich <sleybo at mellanox.co.il> wrote:
> > Fab
> >
> > posting WR with more SGE then the QP capability require the 
> following 
> > error code in post_send
> >    IB_INVALID_MAX_SGE
> >
> > but in post_recv there is no such return value .
> > If we check for the max sge and return such error it should 
> exist in 
> > the recv flow as well.
> > Is this a typo ?
> 
> Looking at the exising code, it looks correct, albeit inconsistent. 
> In the send path, the code uses the internal error code 
> HH_E2BIG_SG_NUM, and then translates that to 
> IB_INVALID_MAX_SGE.  In the receive path, it uses the 
> internal error code HH_EINVAL_SG_NUM.
> 
> In either case, the correct IB_INVALID_MAX_SGE return code 
> should be returned.
> 
> Am I missing something?

We need to add this to the documentation of the IBAL.
( Our verification team check the stack according to the documentation)
I will send patch for that.

> 
> > Actually I prefer to remove all the over head of the error 
> reporting 
> > and just return invalid param for both (including SGE, WR 
> list length 
> > error and WR type error ) what do you think ?
> 
> Are you still going to perform the checks?  If so, returning 
> different error codes should add no overhead at all.  If you 
> want to eliminate the checks that is another thing.
> 
Again I was talking about the documantation.
Lets remove the need to report so many error types.

> If we transition some of these to assertions, we need to make 
> sure to have runtime checks in the proxy or we'll have a 
> security vulnerability.

I will check that after we will stabilize the code and tune for
performance.

> 
> - Fab
> 
> 
>