Date:	Thu, 19 Jun 2008 16:11:14 +0200 (CEST)
From:	"Peter T. Breuer" <ptb@....it.uc3m.es>
To:	linux kernel <linux-kernel@...r.kernel.org>
Subject: zero-copy recv ?

G'day all

I've been mmapping the request's bio buffers received on my block device
driver for userspace to use directly as tcp send/receive buffers.
However ...

  1) this works fantastically for (zero-copy) tcp send (i.e.
    from the address in user space that my mmap trick provides for the
    request buffers),
    
  2) tcp recv hangs.

What's going on? I'd be grateful for any clues as to how to fix this as
it's tcp zero-copy on recv when it goes OK!

What does tcp socket recv need exactly by way of an mmapped buffer?

Is there some set of flags that needs to be set on the pages that make
up the mmap?

Recv() hangs somewhere inside the tcp recv call inside kernel paths that
I cannot trace.  I see "recv(5, ...)" via strace.  The data is sent out
on the wire from the other side and apparently comes in, but the socket
tcp recv never progresses.

If, OTOH, I have previously written the device at that point, then
reading the device causes a request to appear at the device driver
with pages carrying the flags

    40001826

(referenced|error|lru|private|writeback)

and all works fantastically in the sense that recv called with those
pages mmapped into userspace as the recv buffer works just like it
should.

When the device has not been written at that point previously, then
I see pages appearing in the request bio buffers with pretty
random-looking flags, such as

    40020801

(locked|private|readahead)

and recv does its hang trick.

Does anyone have any insight as to what is going on?

Thanks


Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists