Re: [PATCH] An argument for allowing applications to manually send RMPP packets if desired

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Mon, Sep 12, 2011 at 11:29:20AM -0700, Roland Dreier wrote:
> On Mon, Sep 12, 2011 at 10:23 AM, Jason Gunthorpe
> <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> >> It seems at least the SM side could be handled using writev() to
> >> splice together the data it wants to send.
> 
> > How does that help avoid the kernel memory allocations?
> 
> It doesn't, I was only responding to the idea that the SM has to
> rebuild the table for every query.  That issue seems independent
> of where we do RMPP.
> 
>  > I think having the option for RMPP in user space is a good idea, it
>  > allows much more efficiency on the SM side..
> 
> Maybe... but I'd like to explore if there's some way to avoid
> the copying without having to do the full protocol in userspace.

It isn't just the copying. The RMPP protocol is designed to let an SA
generate the response on the fly on a per packet basis. Only a little
bit of RMPP state is required per active session, and no work is
needed before starting to supply response data. This capability cannot
be exposed at all via the kernel interface.

The whole notion of doing RMPP transactions with asynchronous
write/read operation is totally broken from a buffer management
perspective. The fact that it exists at all provides way too many
avenues for user space to OOM the kernel. I hope a remote OOM is not
also possible through this code :(

Jason
--
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