Re: inpcb sip hash mutex contention

2023-06-23 Thread David Gwynne
makes sense to me, ok. maybe it's time to re-evaluate siphash? > On 23 Jun 2023, at 05:50, Alexander Bluhm wrote: > > Hi, > > I am working on a diff to run UDP input in parallel. Btrace kstack > analysis shows that SIP hash for PCB lookup is quite expensive. > When running in parallel we get

Re: profclock, gmonclock: new callbacks for profil(2)/GPROF statclock() code

2023-06-23 Thread Scott Cheloha
On Tue, Jun 20, 2023 at 08:35:11AM -0600, Theo de Raadt wrote: > Claudio Jeker wrote: > > > On Mon, Jun 19, 2023 at 06:41:14PM -0500, Scott Cheloha wrote: > > > > On Jun 19, 2023, at 18:07, Theo de Raadt wrote: > > > > > > > > ???Make sure to STOP all kernel profiling before attempting

Re: smtpd: allow arguments on NOOP

2023-06-23 Thread Todd C . Miller
On Fri, 23 Jun 2023 11:58:47 +0200, Omar Polo wrote: > another diff from the -portable repo: > > https://github.com/OpenSMTPD/OpenSMTPD/pull/1150 > > per rfc-5321 § 4.1.1.9 the NOOP command allows optionally one argument > that we SHOULD ignore. > > The original diff set the check function i

lo(4) loopback LRO and TSO

2023-06-23 Thread Alexander Bluhm
Hi, Claudio@ mentioned the idea to use TSO and LRO on the loopback interface to transfer TCP faster. I see a performance effect with this diff, but more importantly it gives us more test coverage. Currently LRO on lo(4) is default off. Future plan is: - Fix some corner cases for LRO/TSO with TC

Re: Error in ex(1) s command when using c option and numbering on

2023-06-23 Thread Omar Polo
On 2023/06/22 13:18:43 -0600, Todd C. Miller wrote: > On Tue, 07 Feb 2023 20:35:10 -0700, Todd C. Miller wrote: > > > On Tue, 07 Feb 2023 17:17:02 -0700, Todd C. Miller wrote: > > > > > Yes, the bug is that the number is not displayed. The following > > > diff fixes that but there is still a bug

Re: smtpd: allow arguments on NOOP

2023-06-23 Thread gilles
June 23, 2023 11:58 AM, "Omar Polo" wrote: > another diff from the -portable repo: > > https://github.com/OpenSMTPD/OpenSMTPD/pull/1150 > > per rfc-5321 § 4.1.1.9 the NOOP command allows optionally one argument > that we SHOULD ignore. > > The original diff set the check function in the comman

smtpd: allow arguments on NOOP

2023-06-23 Thread Omar Polo
another diff from the -portable repo: https://github.com/OpenSMTPD/OpenSMTPD/pull/1150 per rfc-5321 § 4.1.1.9 the NOOP command allows optionally one argument that we SHOULD ignore. The original diff set the check function in the commands table to NULL because NOOP is not a phase that can