[Patch] Allows tun_mainloop to handle multiple packets in single read.

[David Woodhouse]

On Wed, 2011-11-23 at 19:46 +0900, Kazuyoshi Aizawa wrote:
> It is guaranteed that getmsg would return single message from
> kernel side buffer, aka stream head, and we can expect single
> message contain single packet data as tun driver treats packet
> as single message. By using getmsg, we don't need to care
> about the boundary of the packet data.

Hm, looking at the read(2) manual page¹, shouldn't we be able to put the
tun_fd into 'message-discard' mode, which would make it behave like the
tun device does on other operating systems?

I might have suggested that if I'd realised it yesterday, but now I'm
inclined to stick with the version of your patch that I committed
earlier. It's actually slightly more efficient using getmsg() because of
the MOREDATA flag. With read() we have to keep reading from the tun_fd
until we get EAGAIN, but with getmsg() we can avoid that final
unnecessary system call, because we *know* there's nothing left when the
MOREDATA bit isn't set.

Unless there's some other reason why getmsg() itself is slower than
read(), perhaps?

-- 
dwmw2

¹ http://pubs.opengroup.org/onlinepubs/007904975/functions/read.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20111123/89760d05/attachment.bin>