Re: [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