On 05/21/15 at 03:27P, Lawrence Stewart wrote: > On 05/20/15 23:19, Eric van Gyzen wrote: > > On 05/20/2015 02:33, Lawrence Stewart wrote: > >> On 05/20/15 14:24, Hiren Panchasara wrote: > >>> On 05/20/15 at 02:13P, Lawrence Stewart wrote: > >>>> Hi Hiren, > >>>> > >>>> On 05/20/15 11:08, Hiren Panchasara wrote: > >>>>> Author: hiren Date: Wed May 20 01:08:01 2015 New Revision: > >>>>> 283136 URL: https://svnweb.freebsd.org/changeset/base/283136 > >>>>> > >>>>> Log: Add a new sysctl net.inet.tcp.hostcache.purgenow=1 to > >>>>> expire and purge all entries in hostcache immediately. > >>>>> > >>>>> In collaboration with: bz, rwatson MFC after: 1 week Relnotes: > >>>>> yes Sponsored by: Limelight Networks > >>>> > >>>> Why introduce a new sysctl and not change the existing behaviour > >>>> of net.inet.tcp.hostcache.purge? > >>> > >>> I thought it'd make more sense to keep the existing behavior as is > >>> and provide new knob for the new behavior. > >> > >> Don't think so - why would deferring a purge to the next purge run be > >> useful compared to purging immediately? I'd strongly suggest you adapt > >> this change to the existing purge sysctl. I can't see why anyone would > >> miss the old functionality. > > > > I am generally wary of a question such as "Why would anyone want...", > > because as soon as the code is released, someone answers it. > > > > That being said, I have always wanted Hiren's purgenow behavior, and I've > > always been annoyed by the lazy-purge behavior. I would suggest > > implementing Lawrence's suggestion, but NOT MFC'ing it, since that would be > > a disruptive change. > > > > Thanks for your work, Hiren. > > I see no reason not to MFC it - it's not a POLA violation for a stable > branch. When the user requests a purge, it's surely equally as good (and > I think anyone of right mind would argue better ;) to purge immediately > than some number of seconds "n" in the future, where "n" is between 1 > and the value of net.inet.tcp.hostcache.prune.
I *do* want to MFC the change. And if there are no major objections, I'll go ahead with what Lawrence is suggesting: changing current purge behavior in -head and 10. cheers, Hiren
pgp6X7mRWX5yO.pgp
Description: PGP signature
