[RFC] Suggestion for the improvement of the buffering layer

[Nikos Mavrogiannopoulos]

On Wed, Aug 5, 2009 at 10:32 PM, Jonathan
Bastien-Filiatrault<joe at x2a.org> wrote:

>>  If I understand well you propose using something similar to skb's in
>> linux?  Can you give me an example of your proposal? Say in the TCP case
>> we received a handshake message in 3 different packets and one is not
>> yet received. How the processing will go before the 4th is received and
>> how after that?
>
> The handshake framing layer would determine how many more bytes it needs
> (header present in the first few packets) and compare that with the
> number of bytes available in the record FIFO.

I should add the obvious here that it should check the number of
bytes available in the packets of same type (handshake packets).

> It would return a code
> such as EAGAIN until it has enough data available. When the last packet
> is received, it would dequeue the record packets (possibly splitting a
> partial record packet in two) and memcpy them into a handshake buffer
> and queue the handshake packet in the handshake FIFO. Just to be clear,
> there would be a record FIFO for each upper-layer protocol (demultiplex
> sub-layer).
> 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.

regards,
Nikos