[ClusterLabs/libqb] question about ringbuffer and the MAGIC number

[Hui Xiang]

Hey guys,
  Howdy!
  I am not sure this is the right place to ask, but hope it is : )

  I used to have a problem of corosync 100 cpu problem, which already fixed
in the master branch in function qb_rb_chunk_alloc() there will be a
infinite loop, but after the fix, seems it might failed due
to _rb_chunk_reclai() return -EINVAL on the condition
that (qb_rb_space_free(rb) < (len + QB_RB_CHUNK_MARGIN)), where I got
backtrace:

"""
451                     while (qb_rb_space_free(rb) < (len +
QB_RB_CHUNK_MARGIN)) {
(gdb) p qb_rb_space_free(rb)
$5 = 408
(gdb) p len
$6 = 561

QB_RB_CHUNK_MARGIN apparently equals to 12
#define QB_RB_CHUNK_MARGIN (sizeof(uint32_t) * (QB_RB_CHUNK_HEADER_WORDS +\
                                                QB_RB_WORD_ALIGN +\
                                                QB_CACHE_LINE_WORDS))



qb_rb_chunk_alloc(struct qb_ringbuffer_s * rb, size_t len)
{
       .....
        /*
         * Reclaim data if we are over writing and we need space
         */
        if (rb->flags & QB_RB_FLAG_OVERWRITE) {
                while (qb_rb_space_free(rb) < (len + QB_RB_CHUNK_MARGIN)) {
                        int rc = _rb_chunk_reclaim(rb);
                        if (rc != 0) {
                                errno = rc;
                                return NULL;
                        }
                }

"""

  So do you know how should we control the value of 'len' and where it
comes to avoid failing to call function qb_rb_chunk_alloc(), , is there any
concern with big packets throw to the ringbuffer?  and especially what does
"#define QB_RB_CHUNK_MAGIC  0xA1A1A1A1"  <-  this magic number mean, is
there any document to describe?

Thanks in advance with your great help.

[David Vossel]

----- Original Message -----
>  Hey guys,
>  Howdy!
>  I am not sure this is the right place to ask, but hope it is : ) 
It is, Sorry it has taken me so long to respond.

>  I used to have a problem of corosync 100 cpu problem, which already
> fixed in
>  the master branch in function qb_rb_chunk_alloc() there will be a infinite
>  loop, but after the fix, seems it might failed due to _rb_chunk_reclai()
>  return -EINVAL on the condition that (qb_rb_space_free(rb) < (len + 
This is a bit confusing. I'm assuming the ringbuffer in use here is for shared
memory IPC correct?

With shared memory IPC, the ringbuffer in use is not setup in a way that should
overwrite itself. I wouldn't expect qb_rb_space_reclaim to be invoked during
qb_rb_chunk_alloc. Without the QB_RB_FLAG_OVERWRITE being set, the space is either
free, or we return -EAGAIN which indicates alloc can not occur because of lack
of free space.


If you are using ringbuffer for something outside of IPC and overwrite is in use,
then it's possible you are seeing reclaim errors because you are attempting to
allocate a chunk greater than the entire size of the ringbuffer. This is the only
situation I'd expect reclaim to fail in when overwrite is in use.

-- David



>  QB_RB_CHUNK_MARGIN)), where I got backtrace:
>  
>  """
>  451 while (qb_rb_space_free(rb) < (len + QB_RB_CHUNK_MARGIN)) {
>  (gdb) p qb_rb_space_free(rb)
>  $5 = 408
>  (gdb) p len
>  $6 = 561
>  
>  QB_RB_CHUNK_MARGIN apparently equals to 12
>  #define QB_RB_CHUNK_MARGIN (sizeof(uint32_t) * (QB_RB_CHUNK_HEADER_WORDS +\
>  QB_RB_WORD_ALIGN +\
>  QB_CACHE_LINE_WORDS))
>  
>  
>  
>  qb_rb_chunk_alloc(struct qb_ringbuffer_s * rb, size_t len)
>  {
>  .....
>  /*
>  * Reclaim data if we are over writing and we need space
>  */
>  if (rb->flags & QB_RB_FLAG_OVERWRITE) {
>  while (qb_rb_space_free(rb) < (len + QB_RB_CHUNK_MARGIN)) {
>  int rc = _rb_chunk_reclaim(rb);
>  if (rc != 0) {
>  errno = rc;
>  return NULL;
>  }
>  }
>  
>  """
>  
>  So do you know how should we control the value of 'len' and where it comes to
>  avoid failing to call function qb_rb_chunk_alloc(), , is there any concern
>  with big packets throw to the ringbuffer? and especially what does "#define
>  QB_RB_CHUNK_MAGIC 0xA1A1A1A1" <- this magic number mean, is there any
>  document to describe?
>  
>  Thanks in advance with your great help.
>  
>  
>  
>  
>  _______________________________________________
>  quarterback-devel mailing list
>  quarterback-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/quarterback-devel
>