Lines Matching full:sequence

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
102 sequence number from ``crypto_info``. The driver can add its state
111 of the stream will start exactly at the ``start_offload_tcp_sn`` sequence
112 number, simplifying TCP sequence number matching.
116 the expected sequence number and will have kernel record information.
124 so the initial records' TCP sequence number may be anywhere inside the segment.
134  * record metadata (sequence number, processing offset and length)
135  * expected TCP sequence number
159 Both the device and the driver maintain expected TCP sequence numbers
166 TLS handling and confirms the sequence number matches its expectation.
178 is always TCP). If connection is matched device confirms if the TCP sequence
219 together with its TCP sequence number and TLS record number. The device
225 for a continuation with the crypto state and the new sequence number
237 sequence number is lower than expected the driver assumes retransmission
249 sequence number (as it will be updated from a different context).
256 Next time ``ktls`` pushes a record it will first send its TCP sequence number
307 When the device gets out of sync and the stream reaches TCP sequence
308 numbers more than a max size record past the expected TCP sequence number,
319 really starts there), and which record sequence number the given header had.
321 the record sequence number. Meanwhile, the device had been parsing
327 In a pathological case the device may latch onto a sequence of matching
347 the next expected record number and its TCP sequence number. If the