is dumping structures
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Division,
Technology Unit
Kengo NAKAHARA
to 9.99.100 now.
Thank you for your advise!
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
Thank you for your comment.
On 2022/09/16 15:46, Paul Goyette wrote:
On Fri, 16 Sep 2022, Robert Elz wrote:
Date: Fri, 16 Sep 2022 11:10:30 +0900
From: Kengo NAKAHARA
Message-ID: <90c3c46e-6668-9644-70c3-0eab2cf1c...@iij.ad.jp>
| Hmm, I will test kernel
Hi,
Thank you for your detailed comments!
On 2022/09/15 20:09, Robert Elz wrote:
Date:Thu, 15 Sep 2022 17:08:52 +0900
From:Kengo NAKAHARA
Message-ID: <279eae4e-79f4-39c0-5279-83d5738b6...@iij.ad.jp>
| Can version bump up to 9.99.100? Is there an
,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Division,
Technology Unit
Kengo NAKAHARA
.
http://gnats.netbsd.org/54962
Could you try the patch in PR?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2022/05/27 10:11, Emmanuel Dreyfus wrote:
On Thu, May 26, 2022 at 05:46:31PM +0900, Kengo NAKAHARA wrote:
Could you use head of netbsd-9 branch?
Tried that, workqueue now works fine, and this improves a lot
the behavior against heavy flows.
I am grad to hear that.
Is there a way
Hi,
Thank you for your information.
On 2022/05/26 15:50, Emmanuel Dreyfus wrote:
On Thu, May 26, 2022 at 11:40:15AM +0900, Kengo NAKAHARA wrote:
Hmm, could you send me the result of "dmesg | grep wm0" ?
This is NetBSD-9.2/amd64. It broke with two other acpi devices
starting t
Hi,
On 2022/05/26 11:20, Emmanuel Dreyfus wrote:
On Thu, May 26, 2022 at 10:28:03AM +0900, Kengo NAKAHARA wrote:
When hw.wm0.txrx_workqueue is set to 1, receive and transmit processing
of wm0 uses workqueue(9) instead of softint(9), that is, the processing
can be preempted. As a result
rate. However, that may causes degradation
of throughput and latency.
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2021/01/27 17:56, Martin Husemann wrote:
On Wed, Jan 27, 2021 at 03:44:29PM +0900, Kengo NAKAHARA wrote:
Sorry, I think LP64 system which does not have atomic_64 operations.
Unrelated to this discussion: are there any such systems (that
NetBSD supports)? I am not aware of any, so
Hi,
On 2021/01/27 14:04, Jason Thorpe wrote:
On Jan 26, 2021, at 8:54 PM, Kengo NAKAHARA wrote:
Ah, the stats are just incremented (not atomic ops) because they are
incremented by one CPU or protected by locks. I will enable it as you
say.
My thinking is:
1. Probably not much interest
Hi,
On 2021/01/27 13:36, Jason Thorpe wrote:
On Jan 26, 2021, at 7:51 PM, Kengo NAKAHARA wrote:
Hi,
Thank you for your comments.
On 2021/01/27 12:14, Jason Thorpe wrote:
On Jan 26, 2021, at 6:21 PM, Kengo NAKAHARA wrote:
Someone may worry about any other effects, I will add new kernel
Hi,
Thank you for your comments.
On 2021/01/27 12:14, Jason Thorpe wrote:
On Jan 26, 2021, at 6:21 PM, Kengo NAKAHARA wrote:
Someone may worry about any other effects, I will add new kernel option
WM_DISABLE_EVENT_COUNTERS, please use it.
No strong objection from me, but can we enable
,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
. It works fine for
multiprocessor IP forwarding on my system.
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2019/12/06 18:00, Andrew Doran wrote:
Hi,
On Fri, Dec 06, 2019 at 03:52:23PM +0900, Kengo NAKAHARA wrote:
There are some racy accesses in kern_runq.c detected by KCSAN. Those
racy access messages is so frequency that they cover other messages,
so I want to fix them. They can
Hi,
Thank you for your comment.
On 2019/12/06 16:42, Maxime Villard wrote:
Le 06/12/2019 à 07:52, Kengo NAKAHARA a écrit :
Hi,
There are some racy accesses in kern_runq.c detected by KCSAN. Those
racy access messages is so frequency that they cover other messages,
so I want to fix them
pc = >ci_schedstate;
Can I commit this patch?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
)
Could you comment this KPI name or other idea?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2019/09/06 12:45, Taylor R Campbell wrote:
Date: Fri, 6 Sep 2019 12:17:32 +0900 From: Kengo NAKAHARA
I found workqueue_destroy() for WQ_PERCPU workqueue can cause
hanging up while preempt disabled. The caller of
workqueue_destroy() requires for q_worker kthread to call
kthread_exit
ent Department,
Product Division,
Technology Unit
Kengo NAKAHARA
_4980hq.svg
Wow, excellent scaling! :)
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2017/12/26 17:31, Kengo NAKAHARA wrote:
> Hi,
>
> On 2017/12/25 23:14, Christos Zoulas wrote:
>> On Dec 25, 4:54pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
>> -- Subject: Re: RFC: ipsec(4) pseudo interface
>>
>> | Here is the updated patch series an
Hi,
On 2017/12/25 23:14, Christos Zoulas wrote:
> On Dec 25, 4:54pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: RFC: ipsec(4) pseudo interface
>
> | Here is the updated patch series and unified patch.
> | - https://www.netbsd.org/~knakahara/if_ipse
Hi,
On 2017/12/23 9:05, Christos Zoulas wrote:
> In article <e5721d0b-1b44-612e-a23c-ca5e2af52...@iij.ad.jp>,
> Kengo NAKAHARA <k-nakah...@iij.ad.jp> wrote:
>> Hi,
>>
>> Thank you for your reviewing.
>
>
> Thanks for fixing; more nit-picking
Hi,
I'm sorry, I send mail while editing by mistake.
On 2017/12/20 22:40, Thor Lancelot Simon wrote:
> On Mon, Dec 18, 2017 at 06:49:44PM +0900, Kengo NAKAHARA wrote:
>> Hi,
>>
>> We implement ipsec(4) pseudo interface for route-based VPNs. This pseudo
>> interface man
Hi,
Thank you for your reviewing.
On 2017/12/20 21:08, Christos Zoulas wrote:
> In article <75925357-8e16-0f0f-b7a0-78155c865...@iij.ad.jp>,
> Kengo NAKAHARA <k-nakah...@iij.ad.jp> wrote:
>> Hi,
>>
>> On 2017/12/19 2:54, Christos Zoulas wrote:
>>>
Hi,
On 2017/12/19 11:07, Christos Zoulas wrote:
> In article <20171218184400.ga27...@britannica.bec.de>,
> Joerg Sonnenberger <jo...@bec.de> wrote:
>> On Mon, Dec 18, 2017 at 06:49:44PM +0900, Kengo NAKAHARA wrote:
>>> (a) Add if_ipsec.4
>>> (
Hi,
On 2017/12/19 2:54, Christos Zoulas wrote:
> In article <02c36311-2fcd-08cf-cc71-b472e7c01...@iij.ad.jp>,
> Kengo NAKAHARA <k-nakah...@iij.ad.jp> wrote:
>> Hi,
>>
>> We implement ipsec(4) pseudo interface for route-based VPNs. This pseudo
>>
ring Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2017/12/11 11:09, Taylor R Campbell wrote:
>> Date: Mon, 11 Dec 2017 10:53:11 +0900
>> From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>>
>> Thank you for your reviewing. I see. Here is the updated patch.
>> [...]
>> If there is no problem, can I
Hi,
On 2017/12/09 0:18, Taylor R Campbell wrote:
>> Date: Fri, 8 Dec 2017 18:51:28 +0900
>> From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>>
>> However, it seems your patch has large diff... From the point of code
>> stability, smaller diff SLIST version
ct lwp *psref_lwp;
struct cpu_info *psref_cpu;
Of course, we also think this bug must be fixed before netbsd-8 rc.
Thanks,
--
//////
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
Thank you for your quick response.
On 2017/09/19 14:36, Taylor R Campbell wrote:
>> Date: Tue, 19 Sep 2017 13:38:15 +0900
>> From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>>
>> To fix PR kern/52515(*), in particular psref(9), I implement
>> PERCPU_LIST wh
/
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2017/07/20 23:59, J. Lewis Muir wrote:
> On 07/20, Roy Marples wrote:
>> On 20/07/2017 08:45, Kengo NAKAHARA wrote:
>>> + /*
>>> +* Some encryption devicees(such as mvcesa) is attached before
>>> +* ipi_sysinit(). T
Hi,
On 2017/07/20 18:11, Roy Marples wrote:
> On 20/07/2017 08:45, Kengo NAKAHARA wrote:
>> +/*
>> + * Some encryption devicees(such as mvcesa) is attached before
>> + * ipi_sysinit(). That causes assertion in ipi_register() as
>> + * crypto_ret_s
Hi,
On 2017/07/20 18:07, Martin Husemann wrote:
> On Thu, Jul 20, 2017 at 04:45:08PM +0900, Kengo NAKAHARA wrote:
>> Hi,
>>
>> On 2017/07/19 20:55, Martin Husemann wrote:
>>> On Wed, Jul 19, 2017 at 08:40:27PM +0900, Kengo NAKAHARA wrote:
>>>> I thi
Hi,
On 2017/07/19 20:55, Martin Husemann wrote:
> On Wed, Jul 19, 2017 at 08:40:27PM +0900, Kengo NAKAHARA wrote:
>> I think the reason is mvcesa_attach() is called before ipi_sysinit().
>> Could you try below tentative patch?
>
> Thanks for the quick workaround, it boots
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2017/07/06 18:37, Kengo NAKAHARA wrote:
> Currently, cryptoret() which dequeues from crp_ret_q and calls crp's
> callback function is done in kthread context.
> https://nxr.netbsd.org/xref/src/sys/opencrypto/crypto.c#416
>
> In contrast, crypto_done() which enqueu
be done in kthread
context?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2017/06/19 23:16, Michael van Elst wrote:
> k-nakah...@iij.ad.jp (Kengo NAKAHARA) writes:
>> Today, I found my environment panic while rebooting. As bisecting, it
>> seems the cause is below commit.
>
> Does the following patch help ?
>
ubr_autoconf.c#1728
My environment is amd64 which use sd0(USB Flash) as root filesystem.
Could someone have any solution?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2017/06/12 21:51, Taylor R Campbell wrote:
>> Date: Mon, 12 Jun 2017 10:53:52 +0900
>> From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>>
>> I want to avoid detaching the encryption device while it is used by IPsec.
>> That is, once someone creat
Hi,
On 2017/06/10 1:20, Taylor R Campbell wrote:
>> Date: Fri, 9 Jun 2017 16:50:18 +0900
>> From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>>
>> I tried using localcount(9) for opencyrpto(9) to avoid detach encryption
>> drivers. While I implement that, I wa
Hi,
On 2017/06/09 17:18, Paul Goyette wrote:
> On Fri, 9 Jun 2017, Kengo NAKAHARA wrote:
>> I tried using localcount(9) for opencyrpto(9) to avoid detach encryption
>> drivers. While I implement that, I want to something to use KASSERT which
>> ensure someone have reference o
pment Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2017/06/05 17:43, Kengo NAKAHARA wrote:
> On 2017/05/31 19:19, Shoichi Yamaguchi wrote:
>> Thank you for comments.
>>
>> I modify and rebase the patch.
>> Here is the updated patch:
>>
>> https://gist.githubusercontent.com/s-ymgch2
Hi,
On 2017/06/03 12:17, Michael van Elst wrote:
> k-nakah...@iij.ad.jp (Kengo NAKAHARA) writes:
>
>> Currently(after cryptosoft.c:r1.44), software encryption driver
>> (swcrypto0) is initialized twice, that is, swcr_init() is called
>> below two call paths.
&
Hi,
On 2017/06/01 17:37, Paul Goyette wrote:
> On Thu, 1 Jun 2017, Kengo NAKAHARA wrote:
>> Currently(after cryptosoft.c:r1.44), software encryption driver
>> (swcrypto0) is initialized twice, that is, swcr_init() is called
>> below two call paths.
>>(1) swcrypto_a
opment Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
;
>>
>> Then the scenarios become:
>>
>> 1'. CPU A: localcount_drain (total=0, a=0, b=1)
>>CPU B: localcount_xc(total=1, a=0, b=0)
>>CPU B: localcount_release (total=0, a=0, b=0)
>>
>> 2'. CPU A: localcount_drain (total=0, a=0, b=1)
>>CPU B: localcount_release (total=-1, a=0, b=1)
>>CPU B: localcount_xc(total=0, a=0, b=0)
>
> Makes sense. I've made appropriate changes, and will rebuild and
> re-test.
LGTM, too. Thank you for your fixing.
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
(interlock)
Can "lc->lc_totalp" be -1 at this point?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
ative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
ould you try the newest wm?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2017/02/07 14:01, Kengo NAKAHARA wrote:
> On 2017/01/20 21:26, Kengo NAKAHARA wrote:
>> At first, here is updated patches.
>>
>> http://netbsd.org/~knakahara/if-l2tp-2/01-accept-ifname-include-digit.patch
>>http://netbsd.org/~knakahara/if-l2tp-2/02-
Hi,
On 2017/01/20 21:26, Kengo NAKAHARA wrote:
> At first, here is updated patches.
>http://netbsd.org/~knakahara/if-l2tp-2/01-accept-ifname-include-digit.patch
>http://netbsd.org/~knakahara/if-l2tp-2/02-if-l2tp.patch
I rebase and add some fixes. Here is updated patch set an
Hi,
On 2017/01/20 21:26, Kengo NAKAHARA wrote:
> On 2017/01/20 0:38, Taylor R Campbell wrote:
>>Date: Thu, 19 Jan 2017 17:58:17 +0900
>> From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>>+/*
>>+ * l2tp_variant update API.
>>+ *
>
solution. It may be required to modify
if_clone_create()...
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Campbell wrote:
>Date: Thu, 19 Jan 2017 17:58:17 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
> A few little comments:
>
>diff --git a/sys/net/if.c b/sys/net/if.c
>index 2386af3..ba63266 100644
>--- a/sys/net/if.c
>+++ b/sys/ne
Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2016/12/01 18:40, Kengo NAKAHARA wrote:
> My co-worker Shoichi YAMAGUCHI and I implement pppoe(4) MP-safe.
> # Nearly all parts is written by him, thanks :)
> Here is the patch.
> http://www.netbsd.org/~knakahara/pppoe-mpify/pppoe-mpify.patch
>
> At first, we try
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2016/05/20 22:02, Taylor R Campbell wrote:
>Date: Fri, 20 May 2016 16:28:15 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>I back to gif(4) MP-ify, since I could eliminate bottleneck of
>MP-scalable bridge(4) to support wm(4) TX multiqueue.
>
Hi,
On 2016/06/18 3:56, Taylor R Campbell wrote:
>Date: Fri, 17 Jun 2016 17:57:50 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>I have reconsidered and researched gif(4) implementation, as a result
>I think gif(4) Tx softint(9)
Hi,
On 2016/06/16 16:01, Kengo NAKAHARA wrote:
> On 2016/06/16 15:49, Kengo NAKAHARA wrote:
>> Thank you for your comments.
>> From the above, I update the patch series,
>>
>> http://www.netbsd.org/~knakahara/separate-l3-lock-2/separate-l3-lock-2.tgz
>>
k Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
Thank you for your comments.
On 2016/06/16 12:46, Taylor R Campbell wrote:
>Date: Thu, 16 Jun 2016 12:26:10 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>I rewrite my code. Here is patch series,
>
> http://www.netbsd.org/~knakahara/separa
Hi,
On 2016/06/16 12:26, Kengo NAKAHARA wrote:
> On 2016/06/16 9:47, Kengo NAKAHARA wrote:
>> On 2016/06/14 23:14, Taylor R Campbell wrote:
>>>Date: Tue, 14 Jun 2016 13:33:08 +0900
>>>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
> snip
>>&
Hi,
On 2016/06/16 9:47, Kengo NAKAHARA wrote:
> On 2016/06/14 23:14, Taylor R Campbell wrote:
>>Date: Tue, 14 Jun 2016 13:33:08 +0900
>> From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
snip
>> That said, why not not use two flags, say IFEF_OUTPUT_MPSAFE and
>>
Hi,
On 2016/06/14 23:14, Taylor R Campbell wrote:
>Date: Tue, 14 Jun 2016 13:33:08 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>The design to implement this concept is consisted of below two parts.
>1. at L3 output processing c
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
I found some bugs and missing patch, so I update the patch series and
unified patch, sorry.
On 2016/05/20 22:02, Taylor R Campbell wrote:
>Date: Fri, 20 May 2016 16:28:15 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>I back to gif(4) MP-ify, since
-psref.tgz
And here is the unified patch.
http://www.netbsd.org/~knakahara/gif-psref/unified-gif-psref.patch
Basic design is almost the same as the below patch.
On 2016/03/03 13:31, Kengo NAKAHARA wrote:
> In fist, I reflect your reviews and restructure patch series.
> Here is git format-patch
Hi, riastradh@n.o,
On 2016/04/27 23:49, Taylor R Campbell wrote:
>Date: Wed, 27 Apr 2016 16:27:56 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>On 2016/04/27 0:27, Taylor R Campbell wrote:
>> - Why not call the struct ifnet member `if_enqueue
Hi joerg@n.o,
On 2016/04/27 17:53, Joerg Sonnenberger wrote:
> On Wed, Apr 27, 2016 at 04:27:56PM +0900, Kengo NAKAHARA wrote:
>> I have considered it a little, so that I use if_transmit member directly
>> because of the clean of caller and ifq_enqueue() implementation. I feel
&
Hi,
On 2016/04/27 0:27, Taylor R Campbell wrote:
>Date: Tue, 26 Apr 2016 13:22:40 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>Does anyone have any comments or objections? If there is no objection,
>I will commit this patch after a few days or a few
Hi,
On 2016/04/25 23:17, Joerg Sonnenberger wrote:
> On Mon, Apr 25, 2016 at 01:48:40PM +0900, Kengo NAKAHARA wrote:
>>> Most noticably, it can be used to avoid
>>> ever getting TXEOF interrupts while the device is actively being used.
>>
>> Hmm, do you mean so-
Hi,
On 2016/04/22 16:47, Joerg Sonnenberger wrote:
> On Fri, Apr 22, 2016 at 11:09:24AM +0900, Kengo NAKAHARA wrote:
>> So, I want to introduce new MP-scalable ifnet interface which doesn't
>> use if_snd queue and directly pass mbuf to lower layers. The interface
>>
ents are welcome.
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2016/04/12 12:18, Kengo NAKAHARA wrote:
> On 2016/04/11 17:11, Joerg Sonnenberger wrote:
>> On Mon, Apr 11, 2016 at 01:06:00PM +0900, Kengo NAKAHARA wrote:
>>> I implement moving struct altq_pktattr from m_tag to mbuf. Here is
>>> the patch.
>>>
Hi,
Thank you for comments.
On 2016/04/11 17:11, Joerg Sonnenberger wrote:
> On Mon, Apr 11, 2016 at 01:06:00PM +0900, Kengo NAKAHARA wrote:
>> I implement moving struct altq_pktattr from m_tag to mbuf. Here is
>> the patch.
>>
>> http://www.netbsd.org/~knakahara/
Hi,
On 2016/04/11 13:06, Kengo NAKAHARA wrote:
> On 2016/04/07 8:50, Kengo NAKAHARA wrote:
>> Hi,
>>
>> On 2016/04/05 16:38, Joerg Sonnenberger wrote:
>>> On Tue, Apr 05, 2016 at 01:11:01PM +0900, Kengo NAKAHARA wrote:
>>>> (Q2) How do I decide the dat
Hi,
On 2016/04/07 8:50, Kengo NAKAHARA wrote:
> Hi,
>
> On 2016/04/05 16:38, Joerg Sonnenberger wrote:
>> On Tue, Apr 05, 2016 at 01:11:01PM +0900, Kengo NAKAHARA wrote:
>>> (Q2) How do I decide the data is too large or not?
>>> e.g. ALTQ case, the data is
Hi,
Thank you for quick update!
On 2016/04/08 1:09, Taylor R Campbell wrote:
>Date: Thu, 7 Apr 2016 18:22:08 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>Sorry, I found one more question. _pslist_writer_next_container() does
>not use &qu
Hi,
On 2016/04/08 1:05, Taylor R Campbell wrote:
>Date: Thu, 7 Apr 2016 17:50:56 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>I have a question. It seems that pslist_writer_insert_after() does not
>change old entry->ple_next->ple_prevp. I think
Hi,
On 2016/04/07 17:50, Kengo NAKAHARA wrote:
> Hi,
>
> On 2016/04/04 3:23, Taylor R Campbell wrote:
>>Date: Sun, 3 Apr 2016 18:20:06 +
>>From: Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net>
>>
>>The attached pslist.h i
oT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
On 2016/04/05 16:38, Joerg Sonnenberger wrote:
> On Tue, Apr 05, 2016 at 01:11:01PM +0900, Kengo NAKAHARA wrote:
>> (Q2) How do I decide the data is too large or not?
>> e.g. ALTQ case, the data is struct altq_pktattr whose members are void *,
>> int, and void *.
>>
Hi,
On 2016/04/04 22:05, Thor Lancelot Simon wrote:
> On Mon, Apr 04, 2016 at 05:25:14PM +0900, Kengo NAKAHARA wrote:
>>
>> You are right. Hmm..., I'm sorry, I change my objective. I think it could
>> be better to use pool cache for m_tag itself.
>
> The tags ar
Hi,
On 2016/04/04 2:51, Taylor R Campbell wrote:
>Date: Fri, 1 Apr 2016 20:04:01 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>When I use the kernel built by "build.sh kernel=GENERIC" (the source is
>updated at March 31), I find dtrace(1) e
above patches?
I'm sorry to change later...
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
problem by other way.
Does anyone has any comments about this problem?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
this patch?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
Hi,
Thank you for comments.
On 2016/03/25 23:05, Taylor R Campbell wrote:
>Date: Fri, 25 Mar 2016 17:26:14 +0900
>From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
>I rebase and modify a little(use container_of). Here is the patch.
>
> http://www.n
Hi,
On 2016/03/07 22:20, Kengo NAKAHARA wrote:
> Hi,
>
> On 2016/03/07 19:20, Joerg Sonnenberger wrote:
>> On Tue, Feb 23, 2016 at 01:52:40PM +0900, Kengo NAKAHARA wrote:
>>> Hi,
>>>
>>> I want to uniform IFQ_ENQUEUE arguments whether ALTQ is defined
1 - 100 of 176 matches
Mail list logo
