In D32356#785045, @hselasky wrote:

@jhb : No. The current patch is for -current / main. Do you want me to create such a git repository, or can we use your existing freebsd fork / branch?

@jhb : No. The current patch is for -current / main. Do you want me to create such a git repository, or can we use your existing freebsd fork / branch?

Do you have this pushed to a public branch somewhere (e.g. on GitHub?) It might be easiest to show you what I am saying about how to handle the crypto for the mixed case if I can generate a patch relative to your branch.

I think pushing it and fixing the lagg issue after its in the tree is probably the best path forward.

In D32356#778142, @jhb wrote:

One other structural thing I see is that this still assumes the outbound route path matches the inbound path (using the route to allocate the tag and changing ktls_output_eagain to reset both sessions on a TX failure). But as Drew noted that doesn't work in his setup where the RX and TX can be over different ports in a lagg since the remove end of the lagg can use whatever algorithm it wants to distribute the RX traffic. Instead, we need to store the "leaf" ifp in a new field in m_pkthdr or the like and pass that up through into the socket buffer. At the point of m_demote when we remove the packet header you would want to check for ifp mismatches like we do for output in ip_output_send. Perhaps that can be done as a second round, but then we will just have to revert the ktls_output_eagain() change so I'd rather avoid changing that API just to have to change it back later.

One other structural thing I see is that this still assumes the outbound route path matches the inbound path (using the route to allocate the tag and changing ktls_output_eagain to reset both sessions on a TX failure). But as Drew noted that doesn't work in his setup where the RX and TX can be over different ports in a lagg since the remove end of the lagg can use whatever algorithm it wants to distribute the RX traffic. Instead, we need to store the "leaf" ifp in a new field in m_pkthdr or the like and pass that up through into the socket buffer. At the point of m_demote when we remove the packet header you would want to check for ifp mismatches like we do for output in ip_output_send. Perhaps that can be done as a second round, but then we will just have to revert the ktls_output_eagain() change so I'd rather avoid changing that API just to have to change it back later.

@melifaro @jhb : ping

Rebase.

Rebase patch.

@jhb : Ping.

And for VNET(9) jail, it seems the loopback interface is always configured first.
The behavior is inconsistent with the host.

@jhb: I noticed in the AESNI crypto implementation that it might call malloc() when using the output buffer feature ... and this should be avoided when we already allocated a buffer.

Take @jhb 's suggestion to encrypt a zero'ed mbuf and then XOR.

In D32356#765375, @hselasky wrote:

Rework the re-crypt support. The low level APIs in the crypto framework can apparently only do full encryption and full decryption :-( So use that for now.

Rework the re-crypt support. The low level APIs in the crypto framework can apparently only do full encryption and full decryption :-( So use that for now.

Fix one more compilation issue.

Fix minor compilation issue.

Implement native single-pass recrypt function in the open crypto framework.

Hi John,

Diff reduction.

Rebased patch.

• Rebase patch.
• Properly implement ktls_ocf_tls13_aead_recrypt().

• Catch up with latest INP_FREED changes.
• Fix some compile issues.

Rebase patch.

Oooh, good catch.

In D33210#750542, @kp wrote:

That was done in 3dd5760aa5f876f8a3f0735afeebdf9ee414e1f5, so I'm a little confused where this comes from.

That was done in 3dd5760aa5f876f8a3f0735afeebdf9ee414e1f5, so I'm a little confused where this comes from.

Rebase patch for FreeBSD main branch.

Address comment from @markj .

Add support for VLAN.

Is some description of the changes, or a documentation update, available?

Sorry my bad, resubmit diff as last one include local WIP stashes.

@bryanv

1. Removed redundant error initialization.
2. Moved M_SETFIB(m, sc->vxl_fibnum) out of read lock

Rebase patch on top of latest main branch.

Some other things we talked about on a call today:

Left a few comments. It has been a long while since I've dealt with vxlan - and FreeBSD network stack in general - so somebody more familiar should give a correctness review.

In D32820#741041, @zlei.huang_gmail.com wrote:

I'm glad to do it, but currently if_vxlan is not VNETified and IIUC it is hard to write a regression test for vxlan right now.

Yeah, that's true. If it's not VNET-ready you can't (easily) write tests for it.

In D32820#741027, @kp wrote:

I'm not familiar with the vxlan code but this does look sane.

Let's give Bryan a few more days, but if he's not had the time for this by let's say Monday ping me to commit this.

Also, if someone would feel called to write a regression test for vxlan in general and this new feature specifically I'd love to see it. Something like the basic test in tests/sys/net/if_vlan.sh would already be valuable. (In fact, when I wrote that test it found a panic in the if_vlan code).

I'm glad to do it, but currently if_vxlan is not VNETified and IIUC it is hard to write a regression test for vxlan right now.

In D32820#741028, @melifaro wrote:

LGTM, ty!
Any chance you can fill in the "testing" section?

LGTM, ty!
Any chance you can fill in the "testing" section?

I'm not familiar with the vxlan code but this does look sane.

LGTM for the man page part.

Several fixes and minor improvements.

Fix uninitialized trail_len variable in offload case.

More updates and fixes.

Use next TLS record TCP SN instead of current TLS record. (maybe should pass both so driver can decide)

Fixed some issues with TLS RX resync. Rebased and removed TOE patches.

Add support for TLS RX via LAGG.

Rebase patch and some fixes.

Bugfixes.

Implemented split decryption support.

Update ktls_mbuf_crypto_state() function and rebase.

his "feature" is I believe still needed. I am keeping this alive to help me remember the details and to flag it to others.

@jhb - just put a note here when your done pushing upstream and I'll rebase.

FYI, I'm going to pull out the non-TOE-specific bits of the toe_tls_rxswitch branch and post them for review. Once you are able to rebase on those that will help narrow down the diff a bit.

Include all patches needed on top of the FreeBSD main branch.

Abandoned since it works as intended.

In D31630#713490, @melifaro wrote:

I'd rather not touch it now - there is something WIP that will change this part of the code anyway.

@melifaro Thanks very much!

Done.

Rebased on latest main branch.
Moved down RO_GET_FAMILY()

I'd rather not touch it now - there is something WIP that will change this part of the code anyway.

It's a bit more complex than that.
For the interface routes (e.g. ones w/o the gateway), you may end up with AF_LINK family in RTAX_GATEWAY.
So, you need to check if RTF_GATEWAY is set prior to using RTAX_GATEWAY.