[master] b5443cc8a Make VXID's 64 bit and VRT_INTEGER limited.
Poul-Henning Kamp
phk at phk.freebsd.dk
Mon Jan 23 13:41:48 UTC 2023
--------
Dridi Boukelmoune writes:
> On Mon, Jan 23, 2023 at 11:45 AM Poul-Henning Kamp <phk at freebsd.org> wrote:
> > diff --git a/include/vapi/vsl_int.h b/include/vapi/vsl_int.h
> > index faeb9d111..a40158e04 100644
> > --- a/include/vapi/vsl_int.h
> > +++ b/include/vapi/vsl_int.h
> > @@ -62,9 +62,9 @@
> > * changing corresponding magic numbers in varnishd/cache/cache_shmlog.c
> > */
> >
> > -#define VSL_CLIENTMARKER (1U<<30)
> > -#define VSL_BACKENDMARKER (1U<<31)
> > -#define VSL_IDENTMASK (~(3U<<30))
> > +#define VSL_CLIENTMARKER (1ULL<<62)
> > +#define VSL_BACKENDMARKER (1ULL<<63)
> > +#define VSL_IDENTMASK ((1ULL<<51)-1)
>
> Should we reserve 4 bits to track the ESI level of client requests?
>
> That would set an upper limit of 15 for the max_esi_depth, which is
> probably reasonable. If not, we still have a few more bits that could
> then be (ab)used for faster VSL query processing. Please note that I'm
> very well aware that the current "level" syntax for vslq has nothing
> to do with ESI, so I was also implicitly suggesting we could extend
> VSL filtering and/or to include esi_level.
>
> I understand it is hard to decide on an arbitrary maximum for
> parameters like max_esi_depth, but I'm willing to make that kind of
> trade off.
This reminds me I forgot to update the comment at the top of that file...
We have a fair number of spare bits right now, and I have been thinking
about things to do with them.
I think it would be useful to define a field which VCL can set and
VSLQ filter on.
If people want to stuff the ESI-level in there, they can.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the varnish-commit
mailing list