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

[Jonathan Bastien-Filiatrault]

Nikos Mavrogiannopoulos wrote:
> On Wed, Aug 5, 2009 at 10:32 PM, Jonathan
> Bastien-Filiatrault<address@hidden> wrote:
[snip]
> > Skb's tend to reduce copying to a minimum. In the implementation I
> > suggest I don't see how I can get away with less that one memcpy per
> > layer transition (unless I implement some zero-copy record-slicing
> > code-fu; something I want to avoid).
> > Right, encryption is a few orders of magnitude more costly than memcpy,
> >  in theory I could therefore get away with more memcpy without a
> > significant performance degradation (I won't push this too far, hopefully).
>
> Indeed but don't underestimate memcpy. Both for low latency and high
> speed links (especially with crypto accelerators) that could be the
> bottleneck. Keep that in mind in your design. In any case it doesn't
> look easy task but that's always in the eye of the beholder.

Agreed. You can check http://x2a.org/git/gnutls/?h=buffers-redux for 
preliminary work. I have squashed _gnutls_io_write_buffered and down to 
less than a screenful each. The mbuffers code is now handling partial 
socket writes without problem (and regressions). The code is still 
missing some comments, but you should find it clear after a little 
while. The main benefit at this point is that the buffer logic is 
abstracted away in the mbuffers code and is kept out of the code that 
uses mbuffers.

Your input is very important to me at this point.
> regards,
> Nikos

Cheers,
Jonathan