[RFC] Suggestion for the improvement of the buffering layer

Nikos Mavrogiannopoulos nmav at gnutls.org
Sun Aug 9 21:49:07 CEST 2009

Jonathan Bastien-Filiatrault wrote:

>> - I don't like the malloc for each mbuffer_st being added. I'd suggest
>> to be avoided even if it results to some fixed number of mbuffers per
>> session (which seems quite realistic requirement).
> So do we just allocate a series of maximum-sized buffers (2^14+2048 for
> regular TLS and ~2^16 for DTLS) and keep a free list ? Do we keep a free
> list and realloc if we need more memory ? I do not want to reimplement
> malloc... Is the added complexity worth it ? In the general case,
> mbuffer chains should not be very long...

No actually I was referring to the mbuffer_st structure. As far as I
understand this small structure is getting allocated once we are sending
a message (at least when io_write_buffered() is called). What I suggest
here is that we could avoid that allocation by having some constant
number of them for sending data.

If you want to keep the allocation for the mbuffer_t which will keep the
code simple maybe you can make the callers (now _gnutls_send_int) queue
an mbuffer_t directly. Thus the send_int() will allocate data for
mbuffer_t and the payload using a function such as(example):

mbuffer_st * allocate_with_payload(size_t payload_size)
	mbuffer_st * st;

	st = gnutls_malloc(payload_size+sizeof(mbuffer_st));

	//payload points after the mbuffer_st structure
	st->msg.data = st+sizeof(mbuffer_st);
	st->msg.size = payload_size;

and will fill in the payload and queue it directly down. Once the node
is freed the payload will be freed as well.

Maybe I'm insisting too much here, but I think that your current design
need not to be worse-performance wise from the current one.

Anyway consider my suggestions merely as suggestions. The design looks
good already.

I'll be unavailable for the next few weeks so all best!


More information about the Gnutls-devel mailing list