Ok, so then throwing the memory at a struct and play around with it will not
toggle quoted messageShow quoted text
be a good option. I guess most of this memory will then be accessed by
strict APIs and not as plain bytes.
It sounds like a good plan to get in this direction - will create some work porting
code that access bytes immediately but I guess having a copy-to-consecutive
memory is an option for enabling code that make that assumption (but then
you also get the copying again).
— Joakim Eriksson
On 25 Apr 2016, at 17:15, Jukka Rissanen <jukka.rissanen(a)linux.intel.com> wrote:
the fragments will be individual small buffers with possibly some link
level layer space reserved before the actual data. This way it is
possible to avoid memory copy in lower network levels. If the buf size
is carefully selected for a given bearer technology like 802.15.4, then
we can use the same buffer from application level to the device driver.
On Mon, 2016-04-25 at 16:43 +0200, Joakim Eriksson wrote:
Quick question without a deep dive in the code. Is it intended to
consecutive fragments to allow using the packet/network memory
(e.g. to will a fragmentet buffer look the same as one big buffer)?
In Contiki we have quite often used structs to access data in the
buffer which more or less requires consecutive buffers.
On 25 Apr 2016, at 15:56, Jukka Rissanen <jukka.rissanen(a)linux.inte
I just uploaded net_buf fragmentation support to gerrit.
The fragmentation support allows the network stack to use smaller
buffer fragments to support bigger IP buffers. So instead of
full IPv6 buffer (1280 bytes) we can allocate smaller fragments
instead. This is useful as typically network packets are quite
and always allocating full buffer wastes memory.
This patchset is just an enabler, it does not implement the
fragmentation in the IP stack.
Please review the patchset if this topic interests you.