haproxy/include/common/buffer.h

218 lines
6.3 KiB
C
Raw Normal View History

/*
* include/common/buffer.h
* Buffer management definitions, macros and inline functions.
*
* Copyright (C) 2000-2012 Willy Tarreau - w@1wt.eu
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation, version 2.1
* exclusively.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#ifndef _COMMON_BUFFER_H
#define _COMMON_BUFFER_H
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <common/buf.h>
#include <common/chunk.h>
#include <common/config.h>
#include <common/ist.h>
#include <common/istbuf.h>
#include <common/memory.h>
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
/* an element of the <buffer_wq> list. It represents an object that need to
* acquire a buffer to continue its process. */
struct buffer_wait {
void *target; /* The waiting object that should be woken up */
int (*wakeup_cb)(void *); /* The function used to wake up the <target>, passed as argument */
struct list list; /* Next element in the <buffer_wq> list */
};
extern struct pool_head *pool_head_buffer;
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
extern struct list buffer_wq;
__decl_hathreads(extern HA_SPINLOCK_T buffer_wq_lock);
int init_buffer();
void deinit_buffer();
void buffer_dump(FILE *o, struct buffer *b, int from, int to);
/*****************************************************************/
/* These functions are used to compute various buffer area sizes */
/*****************************************************************/
/* Return 1 if the buffer has less than 1/4 of its capacity free, otherwise 0 */
static inline int buffer_almost_full(const struct buffer *buf)
{
if (b_is_null(buf))
return 0;
MINOR: buffer: add a few basic functions for the new API Here's the list of newly introduced functions : - b_data(), returning the total amount of data in the buffer (currently i+o) - b_orig(), returning the origin of the storage area, that is, the place of position 0. - b_wrap(), pointer to wrapping point (currently data+size) - b_size(), returning the size of the buffer - b_room(), returning the amount of bytes left available - b_full(), returning true if the buffer is full, otherwise false - b_stop(), pointer to end of data mark (currently p+i), used to compute distances or a stop pointer for a loop. - b_peek(), this one will help make the transition to the new buffer model. It returns a pointer to a position in the buffer known from an offest relative to the beginning of the data in the buffer. Thus, we can replace the following occurrences : bo_ptr(b) => b_peek(b, 0); bo_end(b) => b_peek(b, b->o); bi_ptr(b) => b_peek(b, b->o); bi_end(b) => b_peek(b, b->i + b->o); b_ptr(b, ofs) => b_peek(b, b->o + ofs); - b_head(), pointer to the beginning of data (currently bo_ptr()) - b_tail(), pointer to first free place (currently bi_ptr()) - b_next() / b_next_ofs(), pointer to the next byte, taking wrapping into account. - b_dist(), returning the distance between two pointers belonging to a buffer - b_reset(), which resets the buffer - b_space_wraps(), indicating if the free space wraps around the buffer - b_almost_full(), indicating if 3/4 or more of the buffer are used Some of these are provided with the unchecked variants using the "__" prefix, or with the "_ofs" suffix indicating they return a relative position to the buffer's origin instead of a pointer. Cc: Olivier Houchard <ohouchard@haproxy.com>
2018-06-06 12:30:50 +00:00
return b_almost_full(buf);
}
/**************************************************/
/* Functions below are used for buffer allocation */
/**************************************************/
/* Allocates a buffer and assigns it to *buf. If no memory is available,
* ((char *)1) is assigned instead with a zero size. No control is made to
* check if *buf already pointed to another buffer. The allocated buffer is
* returned, or NULL in case no memory is available.
*/
static inline struct buffer *b_alloc(struct buffer *buf)
{
char *area;
*buf = BUF_WANTED;
area = pool_alloc_dirty(pool_head_buffer);
if (unlikely(!area))
return NULL;
buf->area = area;
buf->size = pool_head_buffer->size;
return buf;
}
/* Allocates a buffer and assigns it to *buf. If no memory is available,
* ((char *)1) is assigned instead with a zero size. No control is made to
* check if *buf already pointed to another buffer. The allocated buffer is
* returned, or NULL in case no memory is available. The difference with
* b_alloc() is that this function only picks from the pool and never calls
* malloc(), so it can fail even if some memory is available.
*/
static inline struct buffer *b_alloc_fast(struct buffer *buf)
{
char *area;
*buf = BUF_WANTED;
area = pool_get_first(pool_head_buffer);
if (unlikely(!area))
return NULL;
buf->area = area;
buf->size = pool_head_buffer->size;
return buf;
}
/* Releases buffer <buf> (no check of emptiness) */
static inline void __b_drop(struct buffer *buf)
{
pool_free(pool_head_buffer, buf->area);
}
/* Releases buffer <buf> if allocated. */
static inline void b_drop(struct buffer *buf)
{
if (buf->size)
__b_drop(buf);
}
/* Releases buffer <buf> if allocated, and marks it empty. */
static inline void b_free(struct buffer *buf)
{
b_drop(buf);
*buf = BUF_NULL;
}
/* Ensures that <buf> is allocated. If an allocation is needed, it ensures that
* there are still at least <margin> buffers available in the pool after this
* allocation so that we don't leave the pool in a condition where a session or
* a response buffer could not be allocated anymore, resulting in a deadlock.
* This means that we sometimes need to try to allocate extra entries even if
* only one buffer is needed.
*
* We need to lock the pool here to be sure to have <margin> buffers available
* after the allocation, regardless how many threads that doing it in the same
* time. So, we use internal and lockless memory functions (prefixed with '__').
*/
static inline struct buffer *b_alloc_margin(struct buffer *buf, int margin)
{
char *area;
ssize_t idx;
unsigned int cached;
if (buf->size)
return buf;
cached = 0;
idx = pool_get_index(pool_head_buffer);
if (idx >= 0)
cached = pool_cache[idx].count;
*buf = BUF_WANTED;
#ifndef CONFIG_HAP_LOCKLESS_POOLS
HA_SPIN_LOCK(POOL_LOCK, &pool_head_buffer->lock);
#endif
/* fast path */
if ((pool_head_buffer->allocated - pool_head_buffer->used + cached) > margin) {
area = __pool_get_first(pool_head_buffer);
if (likely(area)) {
#ifndef CONFIG_HAP_LOCKLESS_POOLS
HA_SPIN_UNLOCK(POOL_LOCK, &pool_head_buffer->lock);
#endif
goto done;
}
}
/* slow path, uses malloc() */
area = __pool_refill_alloc(pool_head_buffer, margin);
#ifndef CONFIG_HAP_LOCKLESS_POOLS
HA_SPIN_UNLOCK(POOL_LOCK, &pool_head_buffer->lock);
#endif
if (unlikely(!area))
return NULL;
done:
buf->area = area;
buf->size = pool_head_buffer->size;
return buf;
}
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
/* Offer a buffer currently belonging to target <from> to whoever needs one.
* Any pointer is valid for <from>, including NULL. Its purpose is to avoid
* passing a buffer to oneself in case of failed allocations (e.g. need two
* buffers, get one, fail, release it and wake up self again). In case of
* normal buffer release where it is expected that the caller is not waiting
* for a buffer, NULL is fine.
*/
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
void __offer_buffer(void *from, unsigned int threshold);
static inline void offer_buffers(void *from, unsigned int threshold)
{
HA_SPIN_LOCK(BUF_WQ_LOCK, &buffer_wq_lock);
if (LIST_ISEMPTY(&buffer_wq)) {
HA_SPIN_UNLOCK(BUF_WQ_LOCK, &buffer_wq_lock);
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
return;
}
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
__offer_buffer(from, threshold);
HA_SPIN_UNLOCK(BUF_WQ_LOCK, &buffer_wq_lock);
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
}
#endif /* _COMMON_BUFFER_H */
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/