[RFC] Suggestion for the improvement of the buffering layer
Jonathan Bastien-Filiatrault
joe at x2a.org
Sat Aug 8 19:39:29 CEST 2009
Nikos Mavrogiannopoulos wrote:
> On Wed, Aug 5, 2009 at 10:32 PM, Jonathan
> Bastien-Filiatrault<joe at x2a.org> 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
More information about the Gnutls-devel
mailing list