Why block's buffer was mapped to two address

GNU Radio
1

Hi,
I found block’s buffer was mapped to two continues address, is there any
benefit for this?
When do update reader/writer pointer, I found they was rounded to the
real buffer size, so I want to know which code will use this second half
address?

–
Thanks
Tiankun

2

Hi Tiankun Hu,

I hope I’m answering the right question, but:
gr-buffer maps the same pages into memory multiple times, forming a
pseudo-ring buffer, so that no matter where in your buffer you start,
you always get the full buffer length of “sequential data”. This is very
cool for algorithms that expect consecutive samples, because there’s no
need to find out where the next sample lies – it’s always at the
address right after the last one.

To achieve that, GNU Radio gets pages that can be memory-mapped. For
example, under Linux, we get shared memory segments, and then mmap()
multiple times, right after the last mapping.

When do update reader/writer pointer, I found they was rounded to the
real buffer size, so I want to know which code will use this second
half address?
For example, your Buffer looks like the following:
W = 1kB written by the upstream block, unread (not consume()d) by the
downstream block
R = 1kB already consumed by the downstream block:

W R R R W W

so your read pointer is at the beginning of the fifth kilobyt:

W R R R W W
^
read pointer

Now , we’d like to let the reading block read the whole unread items at
once, i.e. all three W kilobytes. We simply do that by mapping a second
copy right after the first:

W R R R W W|W R R R W W
^
read pointer

After that call, the situation is:

W W W W W W|W W W W W W
^
read pointer

Of course, this isn’t cool – the read pointer should always be within
the buffer size, so we simply do a modulo buffer length :

W W W W W W|W W W W W W
^
read pointer

Best regards,
Marcus

3

Hi Marcus,
Thanks your reply, I got it, it is really cool.
If just mapped to one address, in general_work function user need to
consider whether R/W pointer has out of buffer size, right?

------------------ Original ------------------
From: “Marcus M.”;[email protected];
Date: Mon, Jun 15, 2015 10:03 PM
To: "discuss-gnuradio"[email protected];

Subject: Re: [Discuss-gnuradio] why block’s buffer was mapped to two
address

Hi Tiankun Hu,

I hope I’m answering the right question, but:
gr-buffer maps the same pages into memory multiple times, forming a
pseudo-ring buffer, so that no matter where in your buffer you start,
you always get the full buffer length of “sequential data”. This is very
cool for algorithms that expect consecutive samples, because there’s no
need to find out where the next sample lies – it’s always at the
address right after the last one.

To achieve that, GNU Radio gets pages that can be memory-mapped. For
example, under Linux, we get shared memory segments, and then mmap()
multiple times, right after the last mapping.

When do update reader/writer pointer, I found they was rounded to the
real buffer size, so I want to know which code will use this second
half address?
For example, your Buffer looks like the following:
W = 1kB written by the upstream block, unread (not consume()d) by the
downstream block
R = 1kB already consumed by the downstream block:

W R R R W W

so your read pointer is at the beginning of the fifth kilobyt:

W R R R W W
^
read pointer

Now , we’d like to let the reading block read the whole unread items at
once, i.e. all three W kilobytes. We simply do that by mapping a second
copy right after the first:

W R R R W W|W R R R W W
^
read pointer

After that call, the situation is:

W W W W W W|W W W W W W
^
read pointer

Of course, this isn’t cool – the read pointer should always be within
the buffer size, so we simply do a modulo buffer length :

W W W W W W|W W W W W W
^
read pointer

Best regards,
Marcus

4

On Tue, Jun 16, 2015 at 1:05 AM, Tiankun Hu [email protected]
wrote:

Hi Marcus,
Thanks your reply, I got it, it is really cool.
If just mapped to one address, in general_work function user need to
consider whether R/W pointer has out of buffer size, right?

I wrote up a presentation explaining the stages of the scheduler in more
depth:

Tom