On 28.5.2017. 21:25, Alexander Bluhm wrote:
> On Sun, May 28, 2017 at 07:41:23PM +0200, Hrvoje Popovski wrote:
>> it seems that with
>> $OpenBSD: ip_ipip.c,v 1.81 2017/05/28 13:59:05 bluhm Exp $
>> i can't compile this diff anymore ... with 1.80 everything is fine ...
>> just noticed, nothing else
On Sun, May 28, 2017 at 07:41:23PM +0200, Hrvoje Popovski wrote:
> it seems that with
> $OpenBSD: ip_ipip.c,v 1.81 2017/05/28 13:59:05 bluhm Exp $
> i can't compile this diff anymore ... with 1.80 everything is fine ...
> just noticed, nothing else ...
As I am commiting parts of it, the diff does
On 28.5.2017. 15:07, Alexander Bluhm wrote:
> On Fri, May 26, 2017 at 03:07:51PM +0200, Martin Pieuchot wrote:
>> This diff get rids of the ipintrq for forwarding. The queue is now used
>> for packets delivered locally which still need the KERNEL_LOCK().
> After committing some cleanup mpi@'s
Hello Martin,
I think you need to do NET_UNLOCK() before return (error);
>
> /* Shutdown and remove trunk ports, return on error */
> + NET_LOCK(s);
> while ((tp = SLIST_FIRST(>tr_ports)) != NULL) {
> if ((error = trunk_port_destroy(tp)) != 0)
>
On 28/05/17(Sun) 16:11, Hrvoje Popovski wrote:
> On 28.5.2017. 15:07, Alexander Bluhm wrote:
> > After committing some cleanup mpi@'s diff looks like this now.
> >
> > bluhm
>
>
> Hi all,
>
> with cvs tree fetched few minutes ago and with this diff i'm getting
> traces in attchment.
Thanks
On 28.5.2017. 15:07, Alexander Bluhm wrote:
> After committing some cleanup mpi@'s diff looks like this now.
>
> bluhm
Hi all,
with cvs tree fetched few minutes ago and with this diff i'm getting
traces in attchment.
setup: carp on vlan on trunk (lacp) on 2 x ix
there are so many net diffs,
On Fri, May 26, 2017 at 03:07:51PM +0200, Martin Pieuchot wrote:
> This diff get rids of the ipintrq for forwarding. The queue is now used
> for packets delivered locally which still need the KERNEL_LOCK().
After committing some cleanup mpi@'s diff looks like this now.
bluhm
Index:
This diff get rids of the ipintrq for forwarding. The queue is now used
for packets delivered locally which still need the KERNEL_LOCK().
Since ipv4_input()/ip_forward() no longer need the KERNEL_LOCK() they
are called directly from the 'unlocked' task. That's why the task is
now grabbing the
On Thu, Feb 23, 2017 at 01:57:21PM +0100, Hrvoje Popovski wrote:
> with pflow you get this :)
>
> login: panic: kernel diagnostic assertion "_kernel_lock_held()" failed:
> file "/usr/src/sys/kern/uipc_socket2.c", line 339
/usr/src/regress/sys/net/pflow does not trigger this. There seems
to be
On 23.2.2017. 13:24, Alexander Bluhm wrote:
> On Wed, Feb 22, 2017 at 06:22:56PM +0100, Martin Pieuchot wrote:
>> I'd appreciate if you could test this diff and report regressions.
>
> I did run the regression tests with it. Everything worked fine.
>
>> This cannot be tested if you're using
On 23.2.2017. 13:24, Alexander Bluhm wrote:
> On Wed, Feb 22, 2017 at 06:22:56PM +0100, Martin Pieuchot wrote:
>> I'd appreciate if you could test this diff and report regressions.
>
> I did run the regression tests with it. Everything worked fine.
>
>> This cannot be tested if you're using
On Wed, Feb 22, 2017 at 06:22:56PM +0100, Martin Pieuchot wrote:
> I'd appreciate if you could test this diff and report regressions.
I did run the regression tests with it. Everything worked fine.
> This cannot be tested if you're using NFS, pflow(4) or BFD.
NFS test failed, pflow test
Diff below is what will be committed, or something similar, once all the
issues with the NET_LOCK() are fixed. With it the IPv4 forwarding path
is now executed in the 'softnet' thread, w/o holding the KERNEL_LOCK().
This has already been tested by Hrvoje Popovski who measured an
improvement from
13 matches
Mail list logo
