Re: Possible typo in pf NAT FAQ

Hello, On Sun, Jun 18, 2023 at 06:29:28PM -0600, Ashlen wrote: > On Sun, 18 Jun 2023 20:35 +0200, Stephan Neuhaus wrote: > > Hi list > > > > I think I have found a typo in the pf NAT FAQ here: > > https://www.openbsd.org/faq/pf/nat.html. In the > > "Configuring NAT" section it says: > > > >

Re: huge pfsync rewrite

Hello, On Thu, Jun 29, 2023 at 01:48:27PM +1000, David Gwynne wrote: > On Mon, Jun 26, 2023 at 01:16:40AM +0200, Alexandr Nedvedicky wrote: > > > net/if_pfsync.c > > the diff currently uses two slices (PFSYNC_NSLICES). is there a plan to > > scale it up?

Re: huge pfsync rewrite

Hello, The new code looks much better. It's huge leap forward. I don't mind if this big diff will get committed. Hrvoje did test the whole diff. Trying to split it to smaller changes might bring in code which is not tested enough. We don't know how individual pieces work independently. I've

Re: hardware TSO TCP/IP layer

Hello, I see tcp_dochopper() got committed already... anyway changes here look good. I have no objection. OK sashan

pfsync(4) must protect state with mutex

Hello, diff below has been posted to bugs@ ~week [1] ago. Diff fixes long lasting issue I was scratching my head around for several months. Recently I've shared my itch with bluhm@ who pointed out that `sc_st_mtx` mutex is not sufficient protection. We also need to grab pf_state::mtx when

Re: fragment code cleanup for tso

Hello, On Fri, May 05, 2023 at 11:17:50PM +0200, Alexander Bluhm wrote: > Hi, > > I preparation for my TSO in software diff, I would like to cleanup > the fragment code. Both are very simmilar and I like consistency. > > - Use if_output_ml() to send mbuf lists to interfaces. This can > be

Re: pfioctl: drop net lock from DIOCOSFP{FLUSH,ADD,GET}

Hello, On Sat, May 06, 2023 at 08:56:06PM +, Klemens Nanni wrote: > On Sat, May 06, 2023 at 09:33:05PM +0200, Alexander Bluhm wrote: > > On Sat, May 06, 2023 at 11:11:25AM +, Klemens Nanni wrote: > > > pf_osfp.c contains all the locking for these three ioctls, this removes > > > the net

Re: give softnet threads their own names

On Fri, May 12, 2023 at 10:34:00AM +1000, David Gwynne wrote: > so in top you see softnet0, softnet1, etc. > > the real change is putting a struct softnet in place to wrap the name > and taskq up with. > > ok? sure, thanks sashan

Re: pfioctl: DIOCGETRULESET{,S}: drop net lock

Hello, On Sat, Apr 29, 2023 at 01:37:52PM +, Klemens Nanni wrote: > Both walk the list of rulesets aka. anchors, first one yields a count, > second yields a specific's anchor name. > > Same data access pattern, different copy out, basically. > > pf_anchor_global are contained within

<    2   3   4   5   6   7