[master] 15ec79c Concentrate the acceptor-setup-session code.

Tue Apr 21 23:05:07 CEST 2015

I talked to Artur, and he says that without kernel modifications it did
nothing. Even with kernel modifications to tie specific NICs or flows from
the NICs to specific CPU cores, you only notice a difference when under a
flood.

On Fri, Apr 10, 2015 at 10:59 AM Federico Schwindt <fgsch at lodoss.net> wrote:

> Yes, sorry. I was somewhat hasty when I sent this (I was boarding a plane).
>
> I'm not sure how we can get some metrics without implementing this though.
>
> Perhaps DocWilco has some numbers he can share?
>
> On Fri, Mar 27, 2015 at 8:30 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>
> wrote:
>
>> --------
>> In message <CAJV_h0YFE=
>> 9Ad6dOwf+z5aq3aFqROtzA8kdSowTOYgRRAMv05g at mail.gmail.com>
>> , Federico Schwindt writes:
>>
>> >Attached is a patch in that effect.
>> >
>> >I have no empirical evidence this will improve things but I believe
>> Fastly
>> >and others are doing it with good results.
>>
>> As I understand the documentation of SO_REUSEPORT your patch is a no-op.
>>
>> See for instance:   http://lwn.net/Articles/542629/
>>
>> SO_REUSEPORT allows you to bind(2) multiple sockets to the same port
>> number[1].
>>
>> Setting the option but not creating more sockets doesn't do anything.
>>
>> What we do fall somewhere in the middle between the two scenarios
>> descriped
>> in the article above:  We have a single acceptor thread per thread pool.
>>
>> I have no idea how that performs relative to having multiple sockets, but
>> I'd like to see some actual numbers before we start ripping things up.
>>
>> Poul-Henning
>>
>> [1] You can already do that with UDP under certain circumstances, but it
>>     is not allowed for TCP.
>>
>> --
>> 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.
>>
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20150421/73893acf/attachment.html>