BorisPis

There may be reasons for the user to control whether one offload is used and not the other. For example, if the administrator trusts the crypto offload implementation only for...

> It's already #possible to disable offloading per SA. We don't want to disable it, but rather choose crypto or full offload explicitly. > But is there a use case...

> The silver bullet in term of async file IO on Linux nowadays appears to be `io_uring`. > Another interesting thing is KTLS, which basically allows you to use `sendfile`...

> So, are you suggesting an output uint32_t be added as an output to NDIS_QUIC_CONNECTION, which is then also added to NDIS_QUIC_ENCRYPTION_NET_BUFFER_LIST_INFO in the send path? Yes, exactly. > I...

A connection offload ID sounds to me like a global identifier from the device's perspective rather than an identifier within some protection domain. In general, from the device's perspective, it...

> Pacing can be done two ways: either each packet is posted to the NIC with a timestamp (which feels like what we ideally want to have), or you can...

An additional request is to keep the connection ID as short as possible. I speculate that different devices may have different limitations, in general the shorter the better.

> As previously indicated, we have no control for the TX path. Right, because the client selects the CID. > But even for the RX path, the size and composition...

> Require all offloaded receive direction CIDs to be the same length, globally. That would improve receive offload, if possible please consider doing so. > Restrict the possible lengths of...

Any pointers?