Thanks for your quick response.
> It's because kTLS does a very expensive reallocation and copy for the
> non-zerocopy case (which currently means all of TLS 1.3). I have
> code almost ready to fix that (just needs to be reshuffled into
> upstreamable patches). Brings us up from 5.9 Gbps to 8.4 Gbps per CPU
> on my test box with 16k records. Probably much more than that with
> smaller records.
Happy to hear that, it seems an impressive improvement!
> You'll also need a signed-off-by.
We will do it.
>
> > IDK what this is trying to do but I certainly depends on the fact
> > we run skb_cow_data() and is not "generally correct" :S
>
> Ah also we are not handling partially consumed correctly either.
> Seems we might pop off the skb even when we need to continue;
>
> Maybe look at how skb_copy_datagram_msg() goes below because it
> fixes the skb copy up with the rxm->offset. But, also we need to
> do this repair before sk_psock_tls_strp_read I think so that
> the BPF program reads the correct data in all cases? I guess
> your sample program (and selftests for that matter) just did
> the redirect without reading the data?
Even if our sample program doesn't read data, we can confirm that the
data in the BPF Program are incorrect (no rxm applied).
We will make a change to handle this.
