On Wed, Apr 21, 2021 at 01:15:53PM +, Visa Hankala wrote:
> On Wed, Apr 21, 2021 at 11:04:20AM +1000, David Gwynne wrote:
> > On Wed, Apr 21, 2021 at 10:21:32AM +1000, David Gwynne wrote:
> > > if you have a program that uses kq (or libevent) to wait for bytes to
> > > read off an idle network
Thanks Miod!
Miod Vallat writes:
> The todr_handle struct contains two unused function pointers, which are
> either not implemented or with clones of eopnotsupp(). The following
> diff removes this waste of kernel text.
OK gnezdo if somebody wants to commit.
If art@ comes back to finish this i
On 22.4.2021. 0:31, Alexandr Nedvedicky wrote:
> Hello,
>
>
>>> Hi,
>>>
>>> with this diff i'm getting panic when i'm pushing traffic over that box.
>>> This is plain forwarding. To compile with witness ?
>>
>>
>> with witness
>>
>
> any chance to check other CPUs to see what code they are e
On 22.4.2021. 0:26, Alexander Bluhm wrote:
> On Wed, Apr 21, 2021 at 11:28:17PM +0200, Hrvoje Popovski wrote:
>> with this diff i'm getting panic when i'm pushing traffic over that box.
>
> Thanks for testing.
>
>> I'm sending traffic from host connected on ix0 from address 10.10.0.1 to
>> host c
On Wed, Apr 21, 2021 at 10:50:40PM +0200, Alexander Bluhm wrote:
> > 1108 pfkeyv2_send(struct socket *so, void *message, int len)
> > 1109 {
> >
> > 2013 ipsec_in_use++;
> > 2014 /*
> > 2015 * XXXSMP IPsec data structures are not
Hello,
> > Hi,
> >
> > with this diff i'm getting panic when i'm pushing traffic over that box.
> > This is plain forwarding. To compile with witness ?
>
>
> with witness
>
any chance to check other CPUs to see what code they are executing?
I hope to be lucky enough and see thread, w
On Wed, Apr 21, 2021 at 11:28:17PM +0200, Hrvoje Popovski wrote:
> with this diff i'm getting panic when i'm pushing traffic over that box.
Thanks for testing.
> I'm sending traffic from host connected on ix0 from address 10.10.0.1 to
> host connected to ix1 to addresses 10.11.0.1 - 10.11.255.255
On 21.4.2021. 23:28, Hrvoje Popovski wrote:
> On 21.4.2021. 21:36, Alexander Bluhm wrote:
>> Hi,
>>
>> For a while we are running network without kernel lock, but with a
>> network lock. The latter is an exclusive sleeping rwlock.
>>
>> It is possible to run the forwarding path in parallel on mult
On 21.4.2021. 21:36, Alexander Bluhm wrote:
> Hi,
>
> For a while we are running network without kernel lock, but with a
> network lock. The latter is an exclusive sleeping rwlock.
>
> It is possible to run the forwarding path in parallel on multiple
> cores. I use ix(4) interfaces which provid
On Wed, Apr 21, 2021 at 11:27:15PM +0300, Vitaliy Makkoveev wrote:
> Did you tested your diff with ipsec(4) enabled?
I enable it for the IPsec tests, but disable it for the others.
Doing IPsec policy checks would also slow down non IPsec network
traffic if there is any flow in the kernel.
> I'm a
Hello,
thanks for good news.
On Wed, Apr 21, 2021 at 10:32:08PM +0200, Alexander Bluhm wrote:
> On Wed, Apr 21, 2021 at 09:59:53PM +0200, Alexandr Nedvedicky wrote:
> > was pf(4) enabled while running those tests?
>
> Yes.
>
> > if pf(4) was enabled while those tests were running,
> >
On Wed, Apr 21, 2021 at 09:59:53PM +0200, Alexandr Nedvedicky wrote:
> was pf(4) enabled while running those tests?
Yes.
> if pf(4) was enabled while those tests were running,
> what rules were loaded to to pf(4)?
Default pf.conf:
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04
On Wed, Apr 21, 2021 at 09:36:11PM +0200, Alexander Bluhm wrote:
> Hi,
>
> For a while we are running network without kernel lock, but with a
> network lock. The latter is an exclusive sleeping rwlock.
>
> It is possible to run the forwarding path in parallel on multiple
> cores. I use ix(4) in
Hello,
people who will be running pf(4) with bluhm's diff [1], may trip
one of the asserts triggered by pf_state_key_link_reverse() here:
7366 void
7367 pf_state_key_link_reverse(struct pf_state_key *sk, struct pf_state_key
*skrev)
7368 {
7369 /* Note that sk and skrev may be equal, then
Hello,
just a quick question:
was pf(4) enabled while running those tests?
if pf(4) was enabled while those tests were running,
what rules were loaded to to pf(4)?
my guess is pf(4) was not enabled when running those tests. if I remember
correctly I could see performance boost by fa
Hi,
For a while we are running network without kernel lock, but with a
network lock. The latter is an exclusive sleeping rwlock.
It is possible to run the forwarding path in parallel on multiple
cores. I use ix(4) interfaces which provide one input queue for
each CPU. For that we have to start
The todr_handle struct contains two unused function pointers, which are
either not implemented or with clones of eopnotsupp(). The following
diff removes this waste of kernel text.
Index: arch/sparc64/dev/rtc.c
===
RCS file: /OpenBSD/
Dave Voutila writes:
> vmd(8) users of tech@,
>
> NOTE: I have no intention to try to commit this prior to 6.9's release
> due to its complexity, but I didn't want to "wait" to solicit testers or
> potential feedback.
Freeze is over, so bumping this thread with an updated diff below.
>
> I not
On Wed, Apr 21, 2021 at 11:04:20AM +1000, David Gwynne wrote:
> On Wed, Apr 21, 2021 at 10:21:32AM +1000, David Gwynne wrote:
> > if you have a program that uses kq (or libevent) to wait for bytes to
> > read off an idle network interface via /dev/bpf and that interface
> > goes away, the program d
On Thu, Apr 08, 2021 at 03:35:33AM +0200, Klemens Nanni wrote:
> This scratch has been itching me for far too long and concerns the
> funcionality behind those cwm(1) default bindings:
>
>CM-fToggle full-screen mode of current window.
>CM-mToggle max
There is actually no reason to defer calls to tls_accept_socket() and
tls_connect_socket() in an event callback. The code can be simplified
by a great deal. It also eliminates the issue of keeping a reference
to the listener tls context in the io structure.
Eric.
Index: ioev.c
On Tue, Apr 20, 2021 at 07:59:51PM +0200, Alexander Bluhm wrote:
> I got a positive test report from Paul de Weerd.
>
> Anyone to ok it?
OK claudio@
> On Thu, Mar 18, 2021 at 01:06:49PM +0100, Alexander Bluhm wrote:
> > Hi,
> >
> > While hunting a bug in ntpd offset handling, I found some thin
thanks! happy to include the trailing comma (was already wondering
myself why it had not been there before).
Index: azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.259
diff -u -p -u -p -r1.259 azalia.c
--
On Tue, Apr 13, 2021 at 09:06:12PM +0200, Mark Kettenis wrote:
> > Date: Tue, 13 Apr 2021 19:36:26 +0200
> > From: Rafael Sadowski
> >
> > Based on my cmake pull-request(1) to fix the cmake build on OpenBSD, the
> > following question has arisen which is worth analysing?
> >
> > "It seems OpenBS
24 matches
Mail list logo
