[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [patch #8882] Vector improvements

From: Joel Cunningham
Subject: [lwip-devel] [patch #8882] Vector improvements
Date: Wed, 8 Feb 2017 17:12:17 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0

Follow-up Comment #29, patch #8882 (project lwip):

Sounds good!  From where we left off, there wasn't a conclusion on the way to
represent a set of vectors as they move down the stack (sockets -> netconn ->

We had explored the idea of creating a pbuf chain in the sockets layer (to
avoid introducing a vector type) but then had discussed how a chain of
PBUF_REFs would end up being copied; 1) because tcp_write() doesn't take pbuf
as input and
2) even if we had a tcp_write() that took pbufs, we need a copy since TCP
holds onto the data.  This makes creating the pbuf chain in sockets a wasted

If we refresh on my original patch, it was adding support to
lwip_netconn_do_writemore() to operate on a set of data pointers, calling
tcp_write for each pointer before calling tcp_output (making the send of all
vectors atomic).  There is no in-efficiency here for the vector case, but
there was concern about the added checks for the normal TCP send case (which
becomes a single vector case) because after calling tcp_write(), we do a
couple of small checks to see if there are any more vectors before exiting
do_writemore().  Maybe this is a helpful data point, but other TCP/IP stacks
that I've studied implement send() and sendmsg() in the same pathway, with
send() using a single vector.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]