[Libwebsockets] lws_write speed

Denis Osvald denis.osvald at sartura.hr
Wed May 18 13:46:45 CEST 2016

On 05/18/2016 01:38 PM, Andy Green wrote:
> On 05/18/2016 07:08 PM, Denis Osvald wrote:
>> Hi all,
>> On 05/16/2016 09:33 PM, Pierre Laplante wrote:
>>> In the example of the server, you are using malloc to copy the data
>>> before using lws_write as in:
>>> ...
>>> Is there another way to do this ?
>> Andy, have you looked at the writev syscall, if it's usable in this
>> scenario?
>> It accepts multiple buffers, so it could maybe use the first buffer for
>> the padding thus not requiring user to have padding space in their
>> buffer. It would send them both at once in one writev call then.
>> Maybe it's worth exploring?
> I think it doesn't help with the basic problem, which is that the kernel
> must restrict how much memory it sets aside for buffering a specific
> networking connection.
> Actually writev() semantics seem to be no different than write() in the
> sense it will inform you afterwards how much it actually used
>        On success, readv() and preadv() return the number of bytes read;
> writev() and pwritev() return the number of bytes writ‐
>        ten.  On error, -1 is returned, and errno is set appropriately.
> The basic problem is that the kernel may conclude it only wants to take
> a little of your data into kernelside buffers based on global memory
> situation and the conditions on the specific connection.
> writev() won't magically solve that if I understood it, it's more about
> matching kernelside scatter-gather semantics when there is no special
> restriction on buffering from the driver (ie, storage).

Well, you're right that it wouldn't resolve any of the performance or
bufferring issues.

The only thing that I see writev() helping with is library users not
having to copy data into a new buffer with padding. This would help when
data comes from other sources. E.g. some app uses lws and some libfoo
which allocates and gives back void* foodata + foolen, then app has to
malloc + memcpy because libfoo doesn't provide in-place providing of
data where app would have padding in the buffer as well.

More information about the Libwebsockets mailing list