[openib-general] InfiniPath driver announcement

[Roland Dreier]

    Robert> Is this necessary?  Won't the following fail with ENOMEM
    Robert> anyway if cmd.ne is too big:
    
Yeah, you're right.  For a while in the kernel tree, an oversized
kmalloc() triggered a bug, but it was reverted:
    
    commit dbdb90450059e17e8e005ebd3ce0a1fd6008a0c8
    Author: Andrew Morton <akpm at osdl.org>
    Date:   Fri Sep 23 13:24:10 2005 -0700
    
        [PATCH] revert oversized kmalloc check
    
        As davem points out, this wasn't such a great idea.  There may be
    some code
        which does:
    
            size = 1024*1024;
            while (kmalloc(size, ...) == 0)
                    size /= 2;
    
        which will now explode.
    
        Cc: "David S. Miller" <davem at davemloft.net>
        Cc: Christoph Lameter <christoph at lameter.com>
        Signed-off-by: Andrew Morton <akpm at osdl.org>
        Signed-off-by: Linus Torvalds <torvalds at osdl.org>

I'll delete these checks.

    Robert> Will this work?  If bad_wr is the first wr, then
    Robert> resp.bad_wr will be zero.  The current user code (which
    Robert> has to change anyway) assumes 0 == "no bad wr" and 1 ==
    Robert> "the first wr is the bad wr", etc.

I missed that.  I'll fix up the code locally.

    Robert> One reason why I originally allocated one big wr area
    Robert> instead of a bunch of smaller ones was to keep the cost of
    Robert> this down.  Is it a good idea to be doing this with a
    Robert> bunch of kmallocs?

I think the common case is probably posting a single work request.
And kmalloc() is pretty cheap.  So I think this is OK -- better than
failing when memory gets fragmented.

 - R.