squid-cache
FreeBSD kernel-level TCP proxying (SO_SPLICE) support for plain tunnels
Offload TCP_TUNNEL traffic to kernel using recently added function of FreeBSD. This function is not yet supported by the operating system for KTLS-enabled sockets, which may later be applicable to WebSocket tunnels.
References:
- https://github.com/freebsd/freebsd-src/commit/93ff7dbaea1dac5a6a4309de3780eaf39d52a2a4
- https://github.com/freebsd/freebsd-src/commit/1fe14252227d
- https://man.freebsd.org/cgi/man.cgi?setsockopt
Notes:
- this function is switchable by config option so_splice (default on)
- the timeout of so_splice activated connection is checked per interval and detected within the amount of time specified in config and double of it
- SO_SPLICE is not enabled for delay pool target connections
Hi @rousskov
I've done functional changes to eliminate frequent set/unset of SO_SPLICE. (Polishing is out of scope for now.)
@yadij
Is the position of this tag correct? https://github.com/squid-cache/squid/tree/SQUID_6_14
I noticed the tag is almost neighboring to the HEAD.
Is the position of this tag correct? https://github.com/squid-cache/squid/tree/SQUID_6_14
The current SQUID_6_14 tag (pointing to d4a200022d7c59c95ec0d17c2171ee141e26ed68) and at least some of the corresponding v6.14 release artifacts are wrong -- they are based on recent master/v8 commit instead of the v6 branch! The correct commit for v6.14 is a8c54a8f.
IMHO, besides fixing v6.14, we should release v6.15 ASAP (without any code changes).
Thank you for flagging this serious problem! I continue to beg for more release safeguards/checks, but I have obviously failed to overcome what appears to be fundamental differences in the overall approach.
CC: @kinkie
Hi, the artifacts ("bootstrapped sources..") were correct. The tag was incorrect, and the github-generated source tarball was incorrect as a consequence.
I have now moved the SQUID_6_14 tag to point to the correct commit.
The bootstrapped sources and signatures are unchanged.
You will likely have to git fetch --tags --force to get the correct tag
Francesco
On Fri, Jun 27, 2025 at 3:29 PM Alex Rousskov @.***> wrote:
rousskov left a comment (squid-cache/squid#2095) https://github.com/squid-cache/squid/pull/2095#issuecomment-3013097051
Is the position of this tag correct? https://github.com/squid-cache/squid/tree/SQUID_6_14
The current SQUID_6_14 tag (pointing to d4a2000 https://github.com/squid-cache/squid/commit/d4a200022d7c59c95ec0d17c2171ee141e26ed68) and at least some of the corresponding v6.14 release artifacts are wrong -- they are based on recent master/v8 commit instead of the v6 branch! The correct commit for v6.14 is a8c54a8 https://github.com/squid-cache/squid/commit/a8c54a8f23f0dc41025097caab73ec445f49b78f .
IMHO, besides fixing v6.14, we should release v6.15 ASAP (without any code changes).
Thank you for flagging this serious problem! I continue to beg for more release safeguards/checks, but I have obviously failed to overcome what appears to be fundamental differences in the overall approach.
CC: @kinkie https://github.com/kinkie
— Reply to this email directly, view it on GitHub https://github.com/squid-cache/squid/pull/2095#issuecomment-3013097051, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHPVDGYIOBP35KNQXCXVVT3FVBLHAVCNFSM6AAAAAB75NIW5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJTGA4TOMBVGE . You are receiving this because you were mentioned.Message ID: @.***>
-- Francesco
Something might be wrong with https://github.com/squid-cache/squid/tree/SQUID_6_13 too?
yes; that is known and can't be remediated as the needed commit is missing from the master branch. Teething problems with a new automation I developed for releasing, unfortunately.
On Fri, Jun 27, 2025 at 5:50 PM ss3git @.***> wrote:
ss3git left a comment (squid-cache/squid#2095) https://github.com/squid-cache/squid/pull/2095#issuecomment-3013517034
Something might be wrong with https://github.com/squid-cache/squid/tree/SQUID_6_13 too?
image.png (view on web) https://github.com/user-attachments/assets/d3fbb214-0474-47dc-9942-c63898ab5a89
— Reply to this email directly, view it on GitHub https://github.com/squid-cache/squid/pull/2095#issuecomment-3013517034, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHPVDDEOXG2QMSODIRB3IT3FVR3JAVCNFSM6AAAAAB75NIW5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJTGUYTOMBTGQ . You are receiving this because you were mentioned.Message ID: @.***>
-- Francesco
Something might be wrong with https://github.com/squid-cache/squid/tree/SQUID_6_13 too?
Yes, SQUID_6_13 tag is pointing to a repository commit ada3ca5d993bb61ef7475f5001b35ad362ede6b4 that does not belong to official v6 branch (or any other official repository branch). That commit is not dangling because SQUID_6_13 tag points to it. Normally, Squid release tags point to commits on their respective release branches. Due to an earlier mistake, this one does not.
Since we do not want to rebase/force-push v6, the only way to fix this (AFAICT) is to do something like this:
- Revert all v6 changes since current SQUID_6_13 parent (i.e. since cca68a28). This can be done in one v6 commit X.
- Cherry-pick current SQUID_6_13 into v6, resulting in commit Y (Y parent is X). Retag SQUID_6_13 to point to Y and re-release v6.13.
- Revert X in v6, resulting in the current v6 branch code, but with three "extra" commits: X, Y, and reversal of X. Reversal of X will probably require a trivial conflict resolution (due to Y).
- Possibly re-tag and re-release v6.14 so that SQUID_6_14 comes "after" SQUID_6_13 as far as v6 history is concerned?
None of the above involves rebasing or force-pushing of v6 branch, of course, but it does add a bit of noise to that branch.
It is up to v6 maintainers whether to do something like the above to fix that SQUID_6_13 "commit does not belong to any branch" problem. It is (IMO) a difficult decision!
Cannot create a git commit message from PR title and description.
Error while parsing future commit message title: the line is too long 79>72
Problematic parser input:
FreeBSD kernel-level TCP proxying (SO_SPLICE) support for plain tunnels (#2095)
Please see PR title and description formatting requirements for more details.
This message was added by Anubis bot. Anubis will add a new message if the error text changes. Anubis will remove M-failed-description label when there are no corresponding failures to report.
