[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jonathan Bastien-Filiatrault
Subject: Re: [RFC] Suggestion for the improvement of the buffering layer
Date: Sun, 09 Aug 2009 16:30:12 -0400
User-agent: Mozilla-Thunderbird (X11/20090103)

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


Take care,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]