Re: [PATCH] PPP: Optimize write buffer management

[Patrick Porlan <patrick.porlan@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

Hi Denis,

On Tue, 2011-03-15 at 14:28 -0500, Denis Kenzior wrote:

> Since we're dealing with MTUs of ~1500, our frames don't really ever
> exceed it.  So 256 byte overhead is probably ok, but might be worth
> checking if making this dynamic buys us anything.

Sounds like a good idea. We can expect to save a hundred of bytes or so
per 4 KB buffer in average: I witnessed overhead in the 100~150 bytes
but indeed it may be consistently lower than that, or higher than 256,
depending on the traffic.

> Also, what do you think of growing the overhead and performing the
> framing again in case our estimate is too low?

That becomes even more necessary if we start with a margin we expect to
bump into.

For the record, I tried the g_slice allocator in ringbuffer.c, and can't
really see a performance gain - or loss -, with the downside that there
is no "try" version, and that an allocation failure will therefore fault
the process. As for why it's so, I suppose that even a few thousand
allocations/deallocations only take a few ms. I'm also starting to think
that there is thread aware code in the glib that is not really needed
inside the ofono machinery. I'll send that patch to the list
nonetheless.

Regards,

-- Patrick