[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: Sat, 08 Aug 2009 13:39:29 -0400
User-agent: Mozilla-Thunderbird (X11/20090103)

Nikos Mavrogiannopoulos wrote:
On Wed, Aug 5, 2009 at 10:32 PM, Jonathan
Bastien-Filiatrault<address@hidden> wrote:
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 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.



reply via email to

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