Amaury Denoyelle | 1b5f77f | 2022-05-09 09:37:27 +0200 | [diff] [blame] | 1 | #ifndef _HAPROXY_NCBUF_T_H |
| 2 | #define _HAPROXY_NCBUF_T_H |
| 3 | |
| 4 | /* **** public documentation **** |
| 5 | * |
| 6 | * <ncbuf> stands for non-contiguous circular buffer. This type can be used to |
| 7 | * store data in a non-linear way with gaps between them. The buffer is |
| 8 | * circular and so data may wrapped. |
| 9 | * |
| 10 | * The API of <ncbuf> is splitted in two parts. Please refer to the public API |
| 11 | * declared in this header file which should cover all the needs. |
| 12 | * |
| 13 | * To minimize the memory footprint, size of data and gaps are inserted in the |
| 14 | * gaps themselves. This way <ncbuf> does not need to maintain a separate list |
| 15 | * of data offsets in a dedicated structure. However, this put some limitations |
| 16 | * on the buffer usage that the user need to know. |
| 17 | * |
| 18 | * First, a space will always be reserved in the allocated buffer area to store |
| 19 | * the size of the first data block. Use ncb_size(buf) to retrieve the usable |
| 20 | * size of the allocated buffer excluding the reserved space. |
| 21 | * |
| 22 | * Second, add and deletion operations are constraint and may be impossible if |
| 23 | * a minimal gap size between data is not respected. A caller must always |
| 24 | * inspect the return values of these functions. To limit these errors and |
| 25 | * improve the buffer performance, <ncbuf> should be reserved for use-cases |
| 26 | * where the number of formed gaps is kept minimal and evenly spread. |
| 27 | */ |
| 28 | |
Amaury Denoyelle | d5d2ed9 | 2022-05-09 09:38:45 +0200 | [diff] [blame] | 29 | /* **** internal documentation **** |
| 30 | * |
| 31 | * This section is useful to users who need to understand how ncbuf are |
| 32 | * implemented. |
| 33 | * |
| 34 | * Public and internal functions all shared a common abstraction of the buffer. |
| 35 | * The buffer content is represented as a list of blocks, alternating between |
| 36 | * DATA and GAP blocks. This simplifies the buffer examination loop and |
| 37 | * insertion/deletion. Note that this list of blocks is not stored in the |
| 38 | * buffer structure. |
| 39 | * |
| 40 | * The buffer is considered to always start with a DATA block. The size of this |
| 41 | * block is stored just before <head> which is the pointer for offset 0. This |
| 42 | * space will always be reserved for this usage. It can be accessed through |
| 43 | * ncb_int_head(buf). If the buffer has no data at head, the reserved space |
| 44 | * will simply contains the value 0, and will be follow by a gap. |
| 45 | * |
| 46 | * A gap always contains the size of the gap itself and the size of the next |
| 47 | * data block. Here is a small representation of a gap stored at offset <x> |
| 48 | * before a data block at offset <y>. |
| 49 | * |
| 50 | * x y |
| 51 | * ------------------------------------------------------------ |
| 52 | * xxxxxx| GAP-SZ | DATA-SZ | | xxxxxxxxxxxxx... |
| 53 | * ------------------------------------------------------------ |
| 54 | * | -------- GAP-SZ -------------- > | --- DATA-SZ ---> |
| 55 | * |
| 56 | * This means that a gap must be at least big enough to store two sizes. |
Amaury Denoyelle | edeb0a6 | 2022-05-04 16:16:39 +0200 | [diff] [blame] | 57 | * However, there is an optimization when the last block of the buffer is a |
| 58 | * gap. In this case, there is no minimal size for this block. If the gap is |
| 59 | * too small, the two sizes won't be stored in it. This block is considered |
| 60 | * to be a reduced gap. The block API will detect such a gap if stored at an |
| 61 | * offset near the end of the buffer. |
| 62 | * |
Amaury Denoyelle | d5d2ed9 | 2022-05-09 09:38:45 +0200 | [diff] [blame] | 63 | */ |
| 64 | |
Willy Tarreau | 91a8791 | 2022-05-30 16:37:17 +0200 | [diff] [blame^] | 65 | #include <inttypes.h> |
Amaury Denoyelle | 1b5f77f | 2022-05-09 09:37:27 +0200 | [diff] [blame] | 66 | |
| 67 | /* ncb_sz_t is the basic type used in ncbuf to represent data and gap sizes. |
| 68 | * Use a bigger type to extend the maximum data size supported in the buffer. |
| 69 | * On the other hand, this also increases the minimal gap size which can |
| 70 | * cause more rejection for add/delete operations. |
| 71 | */ |
| 72 | typedef uint32_t ncb_sz_t; |
| 73 | |
| 74 | /* reserved size before head used to store first data block size */ |
| 75 | #define NCB_RESERVED_SZ (sizeof(ncb_sz_t)) |
| 76 | |
| 77 | /* A gap contains its size and the size of the data following it. */ |
| 78 | #define NCB_GAP_MIN_SZ (sizeof(ncb_sz_t) * 2) |
| 79 | #define NCB_GAP_SZ_OFF 0 |
| 80 | #define NCB_GAP_SZ_DATA_OFF (sizeof(ncb_sz_t)) |
| 81 | |
| 82 | #define NCBUF_NULL ((struct ncbuf){ }) |
| 83 | |
| 84 | struct ncbuf { |
| 85 | char *area; |
| 86 | ncb_sz_t size; |
| 87 | ncb_sz_t head; |
| 88 | }; |
| 89 | |
Amaury Denoyelle | 077e096 | 2022-05-09 09:43:11 +0200 | [diff] [blame] | 90 | enum ncb_ret { |
| 91 | NCB_RET_OK = 0, /* no error */ |
| 92 | |
| 93 | NCB_RET_GAP_SIZE, /* operation would create a too small gap */ |
Amaury Denoyelle | b830f0d | 2022-05-09 11:59:15 +0200 | [diff] [blame] | 94 | NCB_RET_DATA_REJ, /* operation would overwrite data with different one */ |
| 95 | }; |
| 96 | |
| 97 | /* Define how insert is conducted in regards with already stored data. */ |
| 98 | enum ncb_add_mode { |
| 99 | NCB_ADD_PRESERVE, /* keep the already stored data and only insert in gaps */ |
| 100 | NCB_ADD_OVERWRT, /* overwrite old data with new ones */ |
| 101 | NCB_ADD_COMPARE, /* compare before insert : if new data are different do not proceed */ |
Amaury Denoyelle | 077e096 | 2022-05-09 09:43:11 +0200 | [diff] [blame] | 102 | }; |
| 103 | |
Amaury Denoyelle | 1b5f77f | 2022-05-09 09:37:27 +0200 | [diff] [blame] | 104 | #endif /* _HAPROXY_NCBUF_T_H */ |