Hi Patrick,
> Is there a particular reason why you chose to use a ring buffer
of ring
> buffers? A simple GQueue might be much easier to understand. If you are
> worried about 'infinite queuing' then a simple counter might help to
> alleviate that.
Well, this implementation opens the door to further optimizations, such
as reusing cells (buffers) to avoid frequent allocation/deallocation.
I think I know where you're going with this, but I'm unconvinced the
circular buffer of buffers is buying you anything over the much simpler
to understand queue of buffers approach.
> You change BUFFER_SIZE from 2048 to 4096 and remove the multiplication
> here. It is a good idea to send these types of changes in a separate
> patch for two reasons:
> - Logically they should be separate
> - It is much easier to review for correctness outside the context of a
> large patch
Got it. By the way, why is it written this way? Is it to stress that we
want space for two frames?
You'd have to ask Marcel, but yes I think this was the intent.
> So I think we have to be a bit careful here. HDLC framing can in
theory
> (if you're maximally unlucky) result in doubling of the data size once
> it is framed. This means that we might have enough space in the current
> buffer according to this estimate, but still exceed it once the actual
> framing is performed. If so, then we have to drop the frame.
>
> There are two possibilities:
> - Retry again with a full buffer this time
> - Always pick a buffer if we have less than 2x size available
>
Thanks for the insight. Picking a new buffer may be best. That will
cause more buffer "run away" though, strengthening the case for better
buffer recycling strategies.
Yes, we definitely want to have some sort of buffer pool management
strategy to share a pool of buffers between different entities (e.g.
GAtMux, GAtServer, GAtHDLC). Have you looked at g_slice* inside glib
yet? I think we can take advantage of the fact that most of our ring
buffers are sized at 4k.
Regards,
-Denis