Re: [RFC] Suggestion for the improvement of the buffering layer

[Nikos Mavrogiannopoulos]

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!

Nikos