Lines Matching full:record

33    abilities or QoS and packet scheduling (``ethtool`` flag ``tls-hw-record``).
42 intercepts them, inserts record framing, performs encryption (in ``TLS_SW``
60 If device decrypted all the segments of the record the decryption is skipped,
100 as well as TLS record sequence number. ``start_offload_tcp_sn`` indicates
101 which TCP sequence number corresponds to the beginning of the record with
116 the expected sequence number and will have kernel record information.
135  * record metadata (sequence number, processing offset and length)
138 There are no guarantees on record length or record segmentation. In particular
139 segments may start at any point of a record and contain any number of records.
150 Record reassembly is not necessary for TLS offload. If the packets arrive
157 The kernel stack performs record framing reserving space for the authentication
168 The device performs encryption and authentication of the record data.
181 (record delineation, decryption, authentication for each record in the packet).
182 The device leaves the record framing unmodified, the stack takes care of record
218 This means most likely that the part of the record preceding the current
220 together with its TCP sequence number and TLS record number. The device
233 Next record sync
241 to the next record state and falls back to software.
257 Next time ``ktls`` pushes a record it will first send its TCP sequence number
258 and TLS record number to the driver. Stack will also make sure that
259 the new record will start on a segment boundary (like it does when
267 when record boundary can be recovered:
280 the next record starts inside 3, based on record length in segment 1.
282 the remainder of the previous record inside segment 3 cannot be handled.
284 and partial block from the new record in segment 3 and when 4 and 5
287 handling. ``ktls`` software fallback handles the decryption of record
292 a record header and arrived after the next record header has already passed:
300 In this example segment 2 gets dropped, and it contains a record header.
302 if it knows the length of the previous record from segment 2. In this case
309 numbers more than a max size record past the expected TCP sequence number,
319 to the kernel, asking if the guessed location is correct (if a TLS record
320 really starts there), and which record sequence number the given header had.
322 the record sequence number. Meanwhile, the device had been parsing
324 of records it had seen to the record number provided by the kernel.
335 asynchronously to the packet stream and record may get processed
348 the next expected record number and its TCP sequence number. If the
380 For example authentication failure for any record in the segment should
417 Offload performance may depend on segment and record size.
464    record could not be found.