[RFC] Suggestion for the improvement of the buffering layer

[Jonathan Bastien-Filiatrault]

Nikos Mavrogiannopoulos wrote:
> 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.

Oh, right. The chain nodes are a small and constant size and as you say, 
that overhead could be reduced.

> 
> 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.

I like this, I will see what I can do...

> 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.

Not problem at all. My current objective is more code simplicity than 
performance at the moment, but I am doing my best to think about 
performance at the same time. Hopefully simpler and smaller code will 
result in less instruction cache misses in the buffer code ;P.

> Anyway consider my suggestions merely as suggestions. The design looks
> good already.
> 
> I'll be unavailable for the next few weeks so all best!

My vacation is ending today... sigh

> Nikos

Take care,
Jonathan