[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: |
Nikos Mavrogiannopoulos |
Subject: |
Re: [RFC] Suggestion for the improvement of the buffering layer |
Date: |
Sun, 09 Aug 2009 22:49:07 +0300 |
User-agent: |
Thunderbird 2.0.0.22 (X11/20090608) |
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
- [RFC] Suggestion for the improvement of the buffering layer, Jonathan Bastien-Filiatrault, 2009/08/04
- Re: [RFC] Suggestion for the improvement of the buffering layer, Nikos Mavrogiannopoulos, 2009/08/05
- Re: [RFC] Suggestion for the improvement of the buffering layer, Jonathan Bastien-Filiatrault, 2009/08/05
- Re: [RFC] Suggestion for the improvement of the buffering layer, Nikos Mavrogiannopoulos, 2009/08/07
- Re: [RFC] Suggestion for the improvement of the buffering layer, Jonathan Bastien-Filiatrault, 2009/08/08
- Re: [RFC] Suggestion for the improvement of the buffering layer, Nikos Mavrogiannopoulos, 2009/08/09
- Re: [RFC] Suggestion for the improvement of the buffering layer, Jonathan Bastien-Filiatrault, 2009/08/09
- Re: [RFC] Suggestion for the improvement of the buffering layer,
Nikos Mavrogiannopoulos <=
- Re: [RFC] Suggestion for the improvement of the buffering layer, Jonathan Bastien-Filiatrault, 2009/08/09