Hi,
On Sat, Mar 23, 2024 at 12:44 AM Edgar Fuß wrote:
>
> Hello.
>
> I'm under the impression that MCLADDREFERENCE() may increment the wrong
> ext_refcnt.
>
> In case it's permitted (I cant't find anything to the contrary) to
> call MCLADDREFERENCE(m1, m2) and then MCLADDREFERENCE(m2, m3), then t
On Tue, Nov 22, 2022 at 8:25 PM Ryota Ozaki wrote:
>
> On Tue, Nov 22, 2022 at 8:00 PM Ryota Ozaki wrote:
> >
> > On Tue, Nov 22, 2022 at 12:49 AM Greg Troxel wrote:
> > >
> > >
> > > Ryota Ozaki writes:
> > >
> > > > I
On Tue, Nov 22, 2022 at 8:00 PM Ryota Ozaki wrote:
>
> On Tue, Nov 22, 2022 at 12:49 AM Greg Troxel wrote:
> >
> >
> > Ryota Ozaki writes:
> >
> > > In the specification DLT_NULL assumes a protocol family in the host
> > > byte order fol
On Tue, Nov 22, 2022 at 12:49 AM Greg Troxel wrote:
>
>
> Ryota Ozaki writes:
>
> > In the specification DLT_NULL assumes a protocol family in the host
> > byte order followed by a payload. Interfaces of DLT_NULL uses
> > bpf_mtap_af to pass a mbuf prepending a pr
On Wed, Nov 9, 2022 at 9:21 PM Greg Troxel wrote:
>
>
> Ryota Ozaki writes:
>
> > NetBSD can't do this because a loopback interface
> > registers itself to bpf as DLT_NULL and bpf treats
> > packets being sent over the interface as AF_UNSPEC.
> > Packets
On Fri, Oct 28, 2022 at 2:53 PM Ryota Ozaki wrote:
>
> On Wed, Oct 26, 2022 at 5:36 PM Ryota Ozaki wrote:
> >
> > On Wed, Oct 26, 2022 at 12:00 AM Christos Zoulas
> > wrote:
> > >
> > > In article
> > > ,
> > > Ryota Ozaki wrote:
&
On Wed, Oct 26, 2022 at 5:36 PM Ryota Ozaki wrote:
>
> On Wed, Oct 26, 2022 at 12:00 AM Christos Zoulas wrote:
> >
> > In article
> > ,
> > Ryota Ozaki wrote:
> > >Hi,
> > >
> > >Data structures of network protocol control blocks
On Wed, Oct 26, 2022 at 12:00 AM Christos Zoulas wrote:
>
> In article
> ,
> Ryota Ozaki wrote:
> >Hi,
> >
> >Data structures of network protocol control blocks (PCBs)
> >(struct inpcb, in6pcb and inpcb_hdr) are not organized well.
> >Users of the data
Hi,
Data structures of network protocol control blocks (PCBs)
(struct inpcb, in6pcb and inpcb_hdr) are not organized well.
Users of the data structures have to handle them separately
and thus the code becomes duplicated and cluttered.
The proposal restructures the data structures, which eliminate
On Wed, Nov 10, 2021 at 6:03 AM Christos Zoulas wrote:
>
> In article <3360841c-e7fc-147d-1347-fe427d41a...@sdf.org>,
> RVP wrote:
> >On Mon, 8 Nov 2021, Jason Thorpe wrote:
> >
> >>> On Nov 7, 2021, at 11:07 PM, RVP wrote:
> >>>
> >>> So, I hacked up a small patch to put most of these into the
On Fri, May 10, 2019 at 7:01 PM Ryota Ozaki wrote:
>
> Hi,
>
> https://www.netbsd.org/~ozaki-r/psref-debug-aggressive.diff
>
> This patch implements yet another psref leak detector that
> enables to tell where a leak occurs while a simpler version
> that is already
Hi,
https://www.netbsd.org/~ozaki-r/psref-debug-aggressive.diff
This patch implements yet another psref leak detector that
enables to tell where a leak occurs while a simpler version
that is already committed just tells an occurrence of a leak.
Investigating of psref leaks is hard because once a
On Thu, Dec 13, 2018 at 6:30 AM Joerg Sonnenberger wrote:
>
> On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote:
> > Before that, I want to ask about how to import cryptography
> > libraries needed tor the implementation. The libraries are
> > libb2[1] and lib
On Thu, Dec 13, 2018 at 2:12 AM Greg Troxel wrote:
>
> m...@netbsd.org writes:
>
> > I don't expect there to be any problems with the ISC license. It's the
> > preferred license for OpenBSD and we use a lot of their code (it's
> > everywhere in sys/dev/)
>
> Agreed that the license is ok.
>
> > ex
Hi,
As you may know I'm working on implementing WireGuard
in the kernel. The implementation works and buildable.
Some code cleanups are still needed but I'll propose it on
the list in the near future.
Before that, I want to ask about how to import cryptography
libraries needed tor the implementa
On Tue, Nov 13, 2018 at 1:26 AM Christos Zoulas wrote:
>
> In article ,
> Greg Troxel wrote:
> >
> >co...@sdf.org writes:
> >
> >> This is an automatically generated list with some hand touchups, feel
> >> free to do whatever with it. I only generated the output.
> >>
> >> ac100ic
> >> acemidi
>
On Thu, Mar 1, 2018 at 5:45 AM, Joerg Sonnenberger wrote:
> On Thu, Mar 01, 2018 at 01:58:29AM +0900, Ryota Ozaki wrote:
>> On Wed, Feb 28, 2018 at 10:11 PM, Joerg Sonnenberger wrote:
>> > On Wed, Feb 28, 2018 at 05:47:13PM +0900, Ryota Ozaki wrote:
>> >> The fea
On Wed, Feb 28, 2018 at 10:11 PM, Joerg Sonnenberger wrote:
> On Wed, Feb 28, 2018 at 05:47:13PM +0900, Ryota Ozaki wrote:
>> The feature is useful when you have a reference to an object that is
>> passed to a callout. In this case you need to take care of a
>> reference
Hi,
This proposal lets callout_reset and callout_schedule return true if
it reschedules a pending callout and return false otherwise.
The feature is useful when you have a reference to an object that is
passed to a callout. In this case you need to take care of a
reference leak on callout_reset (
On Thu, Feb 15, 2018 at 5:30 AM, Mateusz Guzik wrote:
> On Tue, Feb 13, 2018 at 05:14:38PM +0900, Ryota Ozaki wrote:
>> panic: kernel diagnostic assertion "(psref->psref_cpu == curcpu())"
>> failed: file "/(hidden)/sys/kern/subr_psref.c", line 317 passive
On Wed, Feb 14, 2018 at 8:05 AM, Christos Zoulas wrote:
> In article
> ,
> Ryota Ozaki wrote:
>>
>>Is the fix appropriate?
>
> Looks right to me, but it is above my pay grade :-)
Thanks, me too :)
I hope that postponing a migration is not a big deal.
ozaki-r
Hi,
I have been encountering the following panic infrequently
during torture tests.
panic: kernel diagnostic assertion "(psref->psref_cpu == curcpu())"
failed: file "/(hidden)/sys/kern/subr_psref.c", line 317 passive
reference transferred from CPU 0 to CPU 3
fatal breakpoint trap in superviso
On Wed, Feb 7, 2018 at 2:29 PM, Ryota Ozaki wrote:
> On Wed, Feb 7, 2018 at 2:21 PM, Taylor R Campbell
> wrote:
>>> Date: Wed, 7 Feb 2018 14:14:35 +0900
>>> From: Ryota Ozaki
>>>
>>> On Wed, Feb 7, 2018 at 2:55 AM, Taylor R Campbell
>>>
On Wed, Feb 7, 2018 at 2:21 PM, Paul Goyette wrote:
> On Wed, 7 Feb 2018, Ryota Ozaki wrote:
>
>>> a better wording for the manpage could be:
>>>
>>> Test the lock's condition and return non-zero if the lock is
>>> potentially he
On Wed, Feb 7, 2018 at 2:21 PM, Taylor R Campbell
wrote:
>> Date: Wed, 7 Feb 2018 14:14:35 +0900
>> From: Ryota Ozaki
>>
>> On Wed, Feb 7, 2018 at 2:55 AM, Taylor R Campbell
>> wrote:
>> >> Date: Tue, 6 Feb 2018 19:06:33 +0900
>> >> From: R
On Wed, Feb 7, 2018 at 2:55 AM, Taylor R Campbell
wrote:
>> Date: Tue, 6 Feb 2018 19:06:33 +0900
>> From: Ryota Ozaki
>>
>> Is there any reason that rw_lock_held checks if it's held
>> by *someone*, not by curlwp? It's confusable and most (or all?)
>&
On Wed, Feb 7, 2018 at 2:01 AM, Chuck Silvers wrote:
> On Tue, Feb 06, 2018 at 07:06:33PM +0900, Ryota Ozaki wrote:
>> Hi,
>>
>> Is there any reason that rw_lock_held checks if it's held
>> by *someone*, not by curlwp? It's confusable and most (or all?)
&
Hi,
Is there any reason that rw_lock_held checks if it's held
by *someone*, not by curlwp? It's confusable and most (or all?)
users of the API seem to expect the latter (held by curlwp).
Well, rwlock.9 says that rw_*_held behave so, but that's perhaps
just out-of-date because rw_read_held and rw_
On Mon, Jan 29, 2018 at 1:08 PM, Ryota Ozaki wrote:
> Hi,
>
> This proposal extends xcall to allow to specify an IPL of the high
> priority xcall. Currently the high priority xcall uses only a softint
> of IPL_SOFTSERIAL. It doesn't work if the caller depends on
> a differe
Hi,
This proposal extends xcall to allow to specify an IPL of the high
priority xcall. Currently the high priority xcall uses only a softint
of IPL_SOFTSERIAL. It doesn't work if the caller depends on
a different softint IPL.
I'm now working on stability improvements of the network stack
under lo
On Fri, Jan 12, 2018 at 8:27 PM, Taylor R Campbell
wrote:
>> Date: Fri, 12 Jan 2018 04:33:06 + (UTC)
>> From: chris...@astron.com (Christos Zoulas)
>>
>> Even then (with callout_halt) nothing prevents something from
>> calling callout_schedule() or callout_reset() again between
>> that time an
On Fri, Jan 12, 2018 at 1:33 PM, Christos Zoulas wrote:
> In article
> ,
> Ryota Ozaki wrote:
>>Hi,
>>
>>For a certain reason(*), DAD timers are hard to use
>>callout_halt to destroy DAD timer objects. So I was going
>>to fall back to callout_stop (as
Hi,
For a certain reason(*), DAD timers are hard to use
callout_halt to destroy DAD timer objects. So I was going
to fall back to callout_stop (as of NetBSD 7) that is
almost safe but still has a possibility of going wrong(**).
(*) See the thread starting at
http://mail-index.netbsd.org/source-ch
On Fri, Dec 22, 2017 at 4:12 PM, Ryota Ozaki wrote:
> On Thu, Dec 21, 2017 at 5:56 PM, Ryota Ozaki wrote:
>> On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst wrote:
>>> ozak...@netbsd.org (Ryota Ozaki) writes:
>>>
>>>>On Wed, Dec 20, 2017 at 8:06 PM, M
On Thu, Dec 21, 2017 at 5:56 PM, Ryota Ozaki wrote:
> On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst wrote:
>> ozak...@netbsd.org (Ryota Ozaki) writes:
>>
>>>On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote:
>>>> What about a method that waits for a
On Fri, Dec 22, 2017 at 11:33 AM, Ryota Ozaki wrote:
> On Thu, Dec 21, 2017 at 7:45 PM, Frank Kardel wrote:
>> Hi,
>>
>> does this panic (with -current/amd64 as of 20171221) ring a bell with
>> anyone?
>
> Yes. Could you try the patch below?
Oops. The patch wa
On Thu, Dec 21, 2017 at 7:58 PM, Nick Hudson wrote:
> On 12/19/17 08:21, Ryota Ozaki wrote:
>>
>> On Tue, Dec 19, 2017 at 4:52 PM, Nick Hudson
>> wrote:
>>>
>>> On 19/12/2017 03:43, Ryota Ozaki wrote:
>>>
>>>
>>>> BTW
On Thu, Dec 21, 2017 at 7:45 PM, Frank Kardel wrote:
> Hi,
>
> does this panic (with -current/amd64 as of 20171221) ring a bell with
> anyone?
Yes. Could you try the patch below?
Thanks,
ozaki-r
diff --git a/sys/net/if.c b/sys/net/if.c
index 05ac3b2273c..fc3e144373f 100644
--- a/sys/net/if.c
On Wed, Dec 20, 2017 at 5:41 PM, Ryota Ozaki wrote:
> On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette wrote:
>> On Wed, 20 Dec 2017, Ryota Ozaki wrote:
>>
>>> Hi,
>>>
>>> workqueue_destroy requires that its queue doesn't have
>>> any wor
On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst wrote:
> ozak...@netbsd.org (Ryota Ozaki) writes:
>
>>On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote:
>>> What about a method that waits for a specific work to complete?
>
>>It might be useful but how it wor
On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote:
> ozak...@netbsd.org (Ryota Ozaki) writes:
>
>>Here is a patch:
>> http://www.netbsd.org/~ozaki-r/workqueue_drain.diff
>>(I will update workqueue.4 once the proposal is accepted.)
>
> What about a method tha
On Wed, Dec 20, 2017 at 5:41 PM, Ryota Ozaki wrote:
> On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette wrote:
>> On Wed, 20 Dec 2017, Ryota Ozaki wrote:
>>
>>> Hi,
>>>
>>> workqueue_destroy requires that its queue doesn't have
>>> any wor
On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette wrote:
> On Wed, 20 Dec 2017, Ryota Ozaki wrote:
>
>> Hi,
>>
>> workqueue_destroy requires that its queue doesn't have
>> any works (and no new work will be enqueued anymore)
>> before being called. Currently
Hi,
workqueue_destroy requires that its queue doesn't have
any works (and no new work will be enqueued anymore)
before being called. Currently users of workqueue have
to ensure the contract by theirselves. It's possible
but it may need to add extra synchronization mechanisms
such as mutex and cond
On Thu, Dec 14, 2017 at 10:41 PM, Nick Hudson wrote:
>
>
> On 14/12/2017 10:48, Ryota Ozaki wrote:
>>
>> On Fri, Dec 8, 2017 at 7:53 PM, Nick Hudson wrote:
>>
>
>>> Not sure I follow this. I think we agree that the driver should not use
>>>
On Tue, Dec 19, 2017 at 4:52 PM, Nick Hudson wrote:
> On 19/12/2017 03:43, Ryota Ozaki wrote:
>
>
>> BTW I committed a change that disables IFEF_MPSAFE by default on
>> all interfaces because it seems that IFEF_MPSAFE requires additional
>> changes to work safely with
On Fri, Dec 8, 2017 at 7:53 PM, Nick Hudson wrote:
> On 12/06/17 11:11, Ryota Ozaki wrote:
>>
>> On Tue, Nov 28, 2017 at 6:40 PM, Ryota Ozaki
>> wrote:
>>>
>>> On Mon, Nov 27, 2017 at 12:24 AM, Nick Hudson wrote:
>>>>
>>>> On 11/17
On Fri, Dec 8, 2017 at 6:51 PM, Kengo NAKAHARA wrote:
> Hi,
>
> On 2017/12/07 14:21, Taylor R Campbell wrote:
>> I dropped this thread on the floor a while ago and I forget what the
>> status was. I've had a patch sitting in my tree for a while which I
>> brushed off to put the list update logic
On Tue, Nov 28, 2017 at 6:40 PM, Ryota Ozaki wrote:
> On Mon, Nov 27, 2017 at 12:24 AM, Nick Hudson wrote:
>> On 11/17/17 07:44, Ryota Ozaki wrote:
>>>
>>> On Wed, Nov 15, 2017 at 1:53 PM, Ryota Ozaki
>>> wrote:
>>>>
>>>> On Fri, Nov
On Mon, Nov 27, 2017 at 12:24 AM, Nick Hudson wrote:
> On 11/17/17 07:44, Ryota Ozaki wrote:
>>
>> On Wed, Nov 15, 2017 at 1:53 PM, Ryota Ozaki
>> wrote:
>>>
>>> On Fri, Nov 10, 2017 at 6:35 PM, Ryota Ozaki
>>> wrote:
>>>>
>&g
On Mon, Nov 13, 2017 at 12:44 PM, Ryota Ozaki wrote:
> On Sat, Nov 11, 2017 at 1:14 AM, Taylor R Campbell
> wrote:
>>> Date: Fri, 10 Nov 2017 18:54:58 +0900
>>> From: Ryota Ozaki
>>>
>>> Hi,
>>>
>>> I implemented two debugging feat
On Wed, Nov 15, 2017 at 1:53 PM, Ryota Ozaki wrote:
> On Fri, Nov 10, 2017 at 6:35 PM, Ryota Ozaki wrote:
>> Hi,
>>
>> http://www.netbsd.org/~ozaki-r/IFEF_MPSAFE.diff
>>
>> I'm going to commit the above change that integrates
>> IFEF_OUTPUT_MPSAFE and
On Fri, Nov 10, 2017 at 6:35 PM, Ryota Ozaki wrote:
> Hi,
>
> http://www.netbsd.org/~ozaki-r/IFEF_MPSAFE.diff
>
> I'm going to commit the above change that integrates
> IFEF_OUTPUT_MPSAFE and IFEF_START_MPSAFE flags into
> IFEF_MPSAFE.
>
> The motivation is to not
On Wed, Nov 15, 2017 at 3:13 AM, Taylor R Campbell
wrote:
>> Date: Mon, 13 Nov 2017 13:59:32 +0900
>> From: Ryota Ozaki
>>
>> I'm sorry for not replying this thread. I'm back.
>>
>> I've revised the patch as yo
On Tue, Aug 8, 2017 at 3:16 AM, Taylor R Campbell
wrote:
>> Date: Mon, 7 Aug 2017 13:08:35 +0900
>> From: Ryota Ozaki
>>
>> Anyway I've brought another (stupid) approach that uses an atomic
>> counter:
>> http://www.netbsd.org/~ozaki-r/localcount_debug
On Sat, Nov 11, 2017 at 1:14 AM, Taylor R Campbell
wrote:
>> Date: Fri, 10 Nov 2017 18:54:58 +0900
>> From: Ryota Ozaki
>>
>> Hi,
>>
>> I implemented two debugging features for pserialize(9):
>> http://www.netbsd.org/~ozaki-r/debugging-pserialize.diff
Hi,
http://www.netbsd.org/~ozaki-r/IFEF_MPSAFE.diff
I'm going to commit the above change that integrates
IFEF_OUTPUT_MPSAFE and IFEF_START_MPSAFE flags into
IFEF_MPSAFE.
The motivation is to not waste if_extflags bits. I'm now
trying to make if_ioctl() hold KERNEL_LOCK selectively
for some reaso
Hi,
I implemented two debugging features for pserialize(9):
http://www.netbsd.org/~ozaki-r/debugging-pserialize.diff
It detects:
- if a context switch happens in a read section, and
- if a sleepable function is called in a read section.
Any comments or suggestions? Is the implementation correc
On Fri, Oct 6, 2017 at 4:24 PM, Ryota Ozaki wrote:
> On Fri, Oct 6, 2017 at 1:14 PM, Ryota Ozaki wrote:
>> On Fri, Oct 6, 2017 at 11:58 AM, Taylor R Campbell
>> wrote:
>>>> Date: Fri, 6 Oct 2017 11:26:40 +0900
>>>> From: Ryota Ozaki
>>>>
>
On Fri, Oct 6, 2017 at 1:14 PM, Ryota Ozaki wrote:
> On Fri, Oct 6, 2017 at 11:58 AM, Taylor R Campbell
> wrote:
>>> Date: Fri, 6 Oct 2017 11:26:40 +0900
>>> From: Ryota Ozaki
>>>
>>> On Mon, Oct 2, 2017 at 11:13 PM, Taylor R Campbell
>
On Fri, Oct 6, 2017 at 1:21 PM, Taylor R Campbell
wrote:
>> Date: Fri, 6 Oct 2017 13:14:14 +0900
>> From: Ryota Ozaki
>>
>> On Fri, Oct 6, 2017 at 11:58 AM, Taylor R Campbell
>> wrote:
>> > Note that your patch changes the ABI of struct psref!
>>
>
On Fri, Oct 6, 2017 at 11:58 AM, Taylor R Campbell
wrote:
>> Date: Fri, 6 Oct 2017 11:26:40 +0900
>> From: Ryota Ozaki
>>
>> On Mon, Oct 2, 2017 at 11:13 PM, Taylor R Campbell
>> wrote:
>> > Quick summary of the problem:
>> >
>> > Poss
On Mon, Oct 2, 2017 at 11:13 PM, Taylor R Campbell
wrote:
> Quick summary of the problem:
>
>percpu_alloc(9) may move existing per-CPU objects to different
>locations in memory. This means you can't reliably store pointers
>to the per-CPU objects anywhere.
>
>psref(9) currently us
On Tue, Sep 19, 2017 at 1:38 PM, Kengo NAKAHARA wrote:
> Hi,
>
> To fix PR kern/52515(*), in particular psref(9), I implement PERCPU_LIST which
> is dedicated for percpu_alloc'ed percpu struct. Here is the patch which
> consists
> of PERCULI_LIST implementation and applying to subr_psref.c.
>
On Tue, Aug 8, 2017 at 3:07 AM, Taylor R Campbell
wrote:
>> Date: Mon, 7 Aug 2017 12:40:11 +0900
>> From: Ryota Ozaki
>>
>> Thank you for your reviewing! I think I handled all your suggestions.
>> Let me know if I missed or misunderstood something.
>
> Thank
On Thu, Jul 27, 2017 at 1:49 AM, Taylor R Campbell
wrote:
>> Date: Wed, 26 Jul 2017 18:41:36 +0900
>> From: Ryota Ozaki
>>
>> Oops. I thought we could use percpu_foreach in softint, but
>> I was wrong. So localcount_debug_refcnt can be used only
>> in thre
());
rather than writing the constraint in a comment.
Thanks,
ozaki-r
On Fri, Aug 4, 2017 at 12:02 AM, Taylor R Campbell
wrote:
>> Date: Fri, 28 Jul 2017 16:47:15 +0900
>> From: Ryota Ozaki
>>
>> This is a patch to make IPsec SPD MP-safe:
>> http://www.netbsd.org/
Hi,
This is a patch to make IPsec SPD MP-safe:
http://www.netbsd.org/~ozaki-r/mpsafe-ipsec-spd.diff
Please check the locking notes in the patch to know
how I MP-ify SPD.
This is the first time for me to use localcount(9)
so please comment/suggest me on it.
Thanks,
ozaki-r
On Wed, Jul 26, 2017 at 1:34 PM, Ryota Ozaki wrote:
> (resending, please ignore if duplicated)
>
> Hi,
>
> I propose a debugging function of localcount,
> localcount_debug_refcnt, which returns a total
> reference count of a specified localcount.
>
> A result of lo
Hi,
I propose a debugging function of localcount,
localcount_debug_refcnt, which returns a total
reference count of a specified localcount.
A result of localcount_debug_refcnt isn't guaranteed
to be accurate, however it's still useful for
debugging purposes, for example debugging on
ATF tests usi
(resending, please ignore if duplicated)
Hi,
I propose a debugging function of localcount,
localcount_debug_refcnt, which returns a total
reference count of a specified localcount.
A result of localcount_debug_refcnt isn't guaranteed
to be accurate, however it's still useful for
debugging purpos
On Sun, Apr 30, 2017 at 2:04 PM, Paul Goyette wrote:
> On Sun, 30 Apr 2017, Paul Goyette wrote:
>
>> While working on getting the localcount(9) stuff whipped into shape, I ran
>> across a situation where it is desirable to ensure that the current
>> process/lwp does not already own a mutex.
>>
>>
I added tech-toolchain@ where is the best place to discuss this topic.
ozaki-r
On Fri, Apr 14, 2017 at 1:19 PM, Ryota Ozaki wrote:
> On Thu, Apr 13, 2017 at 12:22 PM, Ryota Ozaki wrote:
>> On Wed, Apr 12, 2017 at 6:58 PM, Ryota Ozaki wrote:
>>> On Wed, Apr 12, 2017
On Fri, Apr 14, 2017 at 1:31 PM, Paul Goyette wrote:
> On Fri, 14 Apr 2017, Paul Goyette wrote:
>
>> On Fri, 14 Apr 2017, Ryota Ozaki wrote:
>>
>>>>> If it's useful for other than rump libraries, having a new global
>>>>> option would
On Thu, Apr 13, 2017 at 12:22 PM, Ryota Ozaki wrote:
> On Wed, Apr 12, 2017 at 6:58 PM, Ryota Ozaki wrote:
>> On Wed, Apr 12, 2017 at 9:27 AM, Chuck Silvers wrote:
>>> On Mon, Apr 10, 2017 at 07:22:45PM +0900, Ryota Ozaki wrote:
>>>> Hi,
>>>>
>
On Wed, Apr 12, 2017 at 6:58 PM, Ryota Ozaki wrote:
> On Wed, Apr 12, 2017 at 9:27 AM, Chuck Silvers wrote:
>> On Mon, Apr 10, 2017 at 07:22:45PM +0900, Ryota Ozaki wrote:
>>> Hi,
>>>
>>> I'm using ATF tests running rump kernels (rump_server)
>>>
On Wed, Apr 12, 2017 at 9:27 AM, Chuck Silvers wrote:
> On Mon, Apr 10, 2017 at 07:22:45PM +0900, Ryota Ozaki wrote:
>> Hi,
>>
>> I'm using ATF tests running rump kernels (rump_server)
>> for development and debugging. When a rump kernel gets
>> panic,
On Mon, Apr 10, 2017 at 11:15 PM, Kamil Rytarowski wrote:
> On 10.04.2017 12:22, Ryota Ozaki wrote:
>> Hi,
>>
>> I'm using ATF tests running rump kernels (rump_server)
>> for development and debugging. When a rump kernel gets
>> panic, it dumps a core file f
Hi,
I'm using ATF tests running rump kernels (rump_server)
for development and debugging. When a rump kernel gets
panic, it dumps a core file from which we can obtain
a backtrace by using gdb.
Unfortunately local symbols (i.e., static functions)
in a backtrace are unresolved because they are stri
Hi,
I propose to move if_opackets from device drivers to where
if_obytes is incremented (not just one place), for example
in if_transmit.
The aims of the change are:
- Unify how it's incremented
- Usages of the counter are different between device
drivers
- There are roughly two places
On Sat, Jan 28, 2017 at 9:11 PM, Darren Reed wrote:
> On 27/01/2017 11:51 PM, Ryota Ozaki wrote:
>>
>> On Thu, Jan 26, 2017 at 10:29 AM, Darren Reed wrote:
>>>
>>> Apologies all for the blob of text :(
>>>
>>> I resent with better formatt
On Thu, Jan 26, 2017 at 10:29 AM, Darren Reed wrote:
> Apologies all for the blob of text :(
>
> I resent with better formatting but that's likely in a spam queue
> somewhere...
>
> So I'll try and summarise in a readable fashion:
>
> (1) patch introduces new locks for per-packet processing when t
On Tue, Jan 24, 2017 at 3:47 PM, Ryota Ozaki wrote:
> On Mon, Jan 23, 2017 at 10:01 PM, Thor Lancelot Simon wrote:
>> On Mon, Jan 23, 2017 at 05:58:20PM +0900, Ryota Ozaki wrote:
>>>
>>> The demerit is that that mechanism adds non-trivial
>>> overhead; RTT o
On Mon, Jan 23, 2017 at 10:01 PM, Thor Lancelot Simon wrote:
> On Mon, Jan 23, 2017 at 05:58:20PM +0900, Ryota Ozaki wrote:
>>
>> The demerit is that that mechanism adds non-trivial
>> overhead; RTT of ping increases by 30 usec.
>
> I don't see why overhead for con
Hi,
I propose a controversial change that makes some
pr_input workqueue: icmp_input, icmp6_input and
carp_input.
The reason to do so is that they may add, delete
and update IP addresses and rtentries. If NET_MPSAFE
is enabled, deleting and updating such data require
psz/psref waits (pserialize_pe
On Thu, Jan 19, 2017 at 1:23 PM, Ryota Ozaki wrote:
> On Wed, Jan 18, 2017 at 6:25 PM, Martin Husemann wrote:
>> On Wed, Jan 18, 2017 at 04:48:32PM +0900, Ryota Ozaki wrote:
>>> Note that it of course consumes more CPU time for softint
>>> and more memory for m_dup. T
On Wed, Jan 18, 2017 at 6:25 PM, Martin Husemann wrote:
> On Wed, Jan 18, 2017 at 04:48:32PM +0900, Ryota Ozaki wrote:
>> Note that it of course consumes more CPU time for softint
>> and more memory for m_dup. That said, I think that this is
>> a suitable workaround for no
Hi,
This proposal is a part of the task of MP-safe bpf. To make
the task easy, we want to prevent bpf_mtap* from running
in hardware interrupt context.
By the commit "Move bpf_mtap and if_ipackets++ on Rx of each
driver to percpuq if_input" (*), most bpf_mtap on Rx run in
softint now. However, th
Hi,
This is another proposal that unifies bpf_mtap and
if_ipackets++, which are executed in each driver now,
into the percpuq if_input framework.
The benefits of the change are:
- We can reduce codes
- We can provide the same behavior between drivers
- How if_ipackets is counted up
- Well, ac
On Mon, Dec 5, 2016 at 6:54 PM, Joerg Sonnenberger wrote:
> On Mon, Dec 05, 2016 at 12:16:42PM +0900, Ryota Ozaki wrote:
>> On Fri, Dec 2, 2016 at 7:55 PM, Joerg Sonnenberger wrote:
>> > Especially on older systems, adding non-trivial overhead to RX
>> > processing c
On Fri, Dec 2, 2016 at 7:55 PM, Joerg Sonnenberger wrote:
> On Fri, Dec 02, 2016 at 06:46:12PM +0900, Ryota Ozaki wrote:
>> On Fri, Dec 2, 2016 at 6:32 PM, Joerg Sonnenberger wrote:
>> > On Fri, Dec 02, 2016 at 04:07:24PM +0900, Ryota Ozaki wrote:
>> >> We need it f
On Fri, Dec 2, 2016 at 6:32 PM, Joerg Sonnenberger wrote:
> On Fri, Dec 02, 2016 at 04:07:24PM +0900, Ryota Ozaki wrote:
>> We need it for MP-ification of bpf because some drivers call
>> if_start (or equivalent, say drvX_start) from hardware
>> interrupt, which means that bp
Hi,
This proposal introduces the deferred if_start framework
for network device drivers. It provides a means to schedule
if_start that will be executed in softint later.
We need it for MP-ification of bpf because some drivers call
if_start (or equivalent, say drvX_start) from hardware
interrupt,
Hi,
This is a proposal of changes for MP-safe routing table.
The details of the changes are appended to the end of
the mail (tl;tr).
Here is a patch:
http://www.netbsd.org/~ozaki-r/mpsafe-rt.v0.diff
The changes spread out over many files but the important
changes are in route.c.
Comments or su
On Mon, Nov 7, 2016 at 9:55 PM, Ryota Ozaki wrote:
> On Mon, Nov 7, 2016 at 7:12 PM, Roy Marples wrote:
>> On 07/11/2016 07:30, Ryota Ozaki wrote:
>>> I propose tidy-up of in6_select* functions, esp.
>>> selectroute.
>>
>> ...
>>
>>> The patc
On Mon, Nov 7, 2016 at 7:12 PM, Roy Marples wrote:
> On 07/11/2016 07:30, Ryota Ozaki wrote:
>> I propose tidy-up of in6_select* functions, esp.
>> selectroute.
>
> ...
>
>> The patch is here:
>> http://www.netbsd.org/~ozaki-r/tidyup-in6_select.diff
>>
Hi,
I propose tidy-up of in6_select* functions, esp.
selectroute.
selectroute is annoying because:
- It returns both/either of a rtentry and/or an ifp
- Yes, it may return only an ifp!
- It is valid but selectroute shouldn't handle the case
- Such conditional behavior makes it difficult
On Wed, Sep 7, 2016 at 2:50 PM, Paul Goyette wrote:
> According to the tun(4) man page, you can create an interface "by using the
> ifconfig(8) create command" and this works just fine. The man page goes on
> to say "An open() call on /dev/tunN, will also create a network
> interface..." but this
On Tue, Sep 6, 2016 at 3:14 AM, matthew green wrote:
>> dut1# cpuctl identify 0
>> cpu0: highest basic info 000b
>> cpu0: highest extended info 8008
>> cpu0: "Intel(R) Atom(TM) CPU C2558 @ 2.40GHz"
>> cpu0: Intel Atom C2000 (686-class), 2400.27 MHz
>> cpu0: family 0x6 model 0x4d stepping
On Mon, Sep 5, 2016 at 1:19 PM, matthew green wrote:
> Ryota Ozaki writes:
>> On Thu, Sep 1, 2016 at 4:04 PM, matthew green wrote:
>> > have you tested other values than 1 and 16? what about 4 or 8?
>>
>> 4 and 8 are not so good; their performance fluctuations a
1 - 100 of 371 matches
Mail list logo
