Lines Matching +full:performance +full:- +full:affecting
9 ------------------
15 - We use a sendmmsg/recvmmsg-like API. The alternative API was not considered
19 - We define our own structures rather than using the OS's `struct mmsghdr`.
22 - It ensures portability between OSes and allows the API to be used
25 - It allows us to use structures in keeping with OpenSSL's existing
28 - We do not have to expose functionality which we cannot guarantee
31 - It avoids the need to include OS headers in our own public headers,
35 - For OSes which do not support `sendmmsg`, we emulate it using repeated
40 - We do not define any flags at this time, as the flags previously considered
44 - We ensure the extensibility of our `BIO_MSG` structure in a way that preserves
51 - The BIO methods are designed to support stateless operation in which they
58 need to be synchronised with a lock, undermining performance on what (for
61 - We do not support iovecs. The motivations for this are:
63 - Not all platforms can support iovecs (e.g. Windows).
65 - The only way we could emulate iovecs on platforms which don't support
68 zero/single-copy requirements. Moreover, it would lead to extremely
69 surprising performance variations for consumers of the API.
71 - We do not believe iovecs are needed to meet our performance requirements
78 - Even if we did support iovecs, we would have to impose a limit
81 stateless and not requiire locking. Therefore the OS-native iovec structures
84 - Sometimes, an application may wish to learn the local interface address
91 this on-demand would require state in the BIO to determine whether this
93 unnecessary locking, undermining performance in concurrent usage of this API
96 performance cost. It also aids users of the API to understand that this
123 - `msg` points to an array of `num_msg` `BIO_MSG` structures.
125 - Both functions have identical prototypes, and return the number of messages
126 processed in the array. If no messages were sent due to an error, `-1` is
127 returned. If an OS-level socket error occurs, a negative value `v` is
128 returned. The caller should determine that `v` is an OS-level socket error by
129 calling `BIO_IS_ERRNO(v)` and may obtain the OS-level socket error code by
132 - `stride` must be set to `sizeof(BIO_MSG)`.
134 - `data` points to the buffer of data to be sent or to be filled with received
140 - `flags` in the `BIO_MSG` structure provides per-message flags to
144 affecting all messages in the array. Currently, no per-message or global flags
147 - `peer` and `local` are optional pointers to `BIO_ADDR` structures into
152 messages processed, or -1 if the message in question is the first message.)
170 -----------------------------
174 ### sendmmsg/recvmmsg-like API
202 - Are `BIO_mmsghdr`, `BIO_msghdr` and `BIO_iovec` simple typedefs
203 for OS-provided structures, or our own independent structure
206 - If we use OS-provided structures:
208 - We would need to include the OS headers which provide these
211 - If we choose to support these functions when OS support is not available
215 - If we use our own structures:
217 - We would need to translate these structures during every call.
261 - We also need to decide what to do for OSes which don't support at least
264 - Don't provide these functions and require all users of these functions to
267 - Not providing these functions on OSes that don't support
270 to code more realistic performance expectations since it
273 - Provide these functions and emulate the functionality:
275 - However there is a question here as to how we implement
280 iovecs and providing a performance profile which is surprising to code
283 - Another option could be a variable limit on the number of iovecs,
287 BIO_dgram, but it seems the only way to avoid the surprising performance
303 The problem here is we want to support “single-copy” (where the data is only
364 call with an excessive number of arguments or pointers to unwieldy ever-growing
382 - Application can generate one datagram at a time and still get the advantages
392 - Flexible support for single-copy (zero-copy).
396 - Very different way of doing reads/writes might be strange to existing
407 2. BIO_read_dequeue (`recvmmsg` based call path with callback-allocated buffer)
413 `BIO_read_dequeue` path. We use an OpenSSL-provided default allocator
438 RX queue. In this case we do have to copy - we have no choice. However this only
450 - After the first call to `BIO_read_dequeue` is made on a BIO_dgram, all
459 legacy and zero-copy code paths.
473 would need to revisit the set-call-then-execute-call API approach above