On 21/04/15 15:39, Hui Xiang wrote:
> In the master branch function qb_rb_chunk_alloc() maybe 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(), I can
> reproduce this problem by setting one of the corosync node nic into 5000
> mtu, others are staying at 1500 everywhere, is it related about the big
> packets throw to the ringbuffer?
>
I don't honestly know, I'm not familiar with that code. I'll ask one of
the libqb developers.
Chrissie
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
