dumping structures
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Division,
Technology Unit
Kengo NAKAHARA
patch and bump up 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
it may hit the following issue.
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 it
,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
ue=1) and NET_MPSAFE=on kernel. 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 be
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
tspc = &tci->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
intel_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 ,
> Kengo NAKAHARA wrote:
>> Hi,
>>
>> Thank you for your reviewing.
>
>
> Thanks for fixing; more nit-picking:
> 1. there is a variable called err instead of error why (all the rest
>are c
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
>> interfac
Hi,
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 manages its security policy(SP) by i
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 wrote:
>> Hi,
>>
>> On 2017/12/19 2:54, Christos Zoulas wrote:
>>> In article <02c3
Hi,
On 2017/12/19 11:07, Christos Zoulas wrote:
> In article <20171218184400.ga27...@britannica.bec.de>,
> Joerg Sonnenberger wrote:
>> On Mon, Dec 18, 2017 at 06:49:44PM +0900, Kengo NAKAHARA wrote:
>>> (a) Add if_ipsec.4
>>> (b) move current ipsec.4
Hi,
On 2017/12/19 2:54, Christos Zoulas wrote:
> In article <02c36311-2fcd-08cf-cc71-b472e7c01...@iij.ad.jp>,
> Kengo NAKAHARA wrote:
>> Hi,
>>
>> We implement ipsec(4) pseudo interface for route-based VPNs. This pseudo
>> interface manages its security pol
ring Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2017/12/11 11:09, Taylor R Campbell wrote:
>> Date: Mon, 11 Dec 2017 10:53:11 +0900
>> From: Kengo NAKAHARA
>>
>> Thank you for your reviewing. I see. Here is the updated patch.
>> [...]
>> If there is no problem, can I commit and pullup -8 the patch?
Hi,
On 2017/12/09 0:18, Taylor R Campbell wrote:
>> Date: Fri, 8 Dec 2017 18:51:28 +0900
>> From: Kengo NAKAHARA
>>
>> However, it seems your patch has large diff... From the point of code
>> stability, smaller diff SLIST version would be better for netbsd-8 bra
d before netbsd-8 rc.
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
/
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
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
>>
>> To fix PR kern/52515(*), in particular psref(9), I implement
>> PERCPU_LIST which is dedicated for percpu_a
///
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
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(). That c
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
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 enqu
must be done in kthread
context?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
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
Hi,
On 2017/06/12 21:51, Taylor R Campbell wrote:
>> Date: Mon, 12 Jun 2017 10:53:52 +0900
>> From: Kengo NAKAHARA
>>
>> I want to avoid detaching the encryption device while it is used by IPsec.
>> That is, once someone creates Security Assocatation(SA) to ca
Hi,
On 2017/06/10 1:20, Taylor R Campbell wrote:
>> Date: Fri, 9 Jun 2017 16:50:18 +0900
>> From: Kengo NAKAHARA
>>
>> I tried using localcount(9) for opencyrpto(9) to avoid detach encryption
>> drivers. While I implement that, I want to something to use KASSER
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
Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
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
epartment,
Network Division,
Technology Unit
Kengo NAKAHARA
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
utex_exit(interlock);
>>
>> 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
utex_enter(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
Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
w.
Could you try the newest wm?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
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-if-l
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
>>+/*
>>+ * l2tp_variant update API.
>>+ *
>>+ * Assumption:
>>
on't have an appropriate 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
Campbell wrote:
>Date: Thu, 19 Jan 2017 17:58:17 +0900
>From: Kengo NAKAHARA
> 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/net/if.c
>@@ -1599,7 +1613,7 @@ if_cl
create of such interface.
Could anyone have any ideas about this?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
twork Division,
Technology Unit
Kengo NAKAHARA
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
Hi,
On 2016/06/28 20:03, Kengo NAKAHARA wrote:
> On 2016/05/20 22:02, Taylor R Campbell wrote:
>>Date: Fri, 20 May 2016 16:28:15 +0900
>> From: Kengo NAKAHARA
>>
>>I back to gif(4) MP-ify, since I could eliminate bottleneck of
>>MP-scalable bridge(
Hi,
On 2016/05/20 22:02, Taylor R Campbell wrote:
>Date: Fri, 20 May 2016 16:28:15 +0900
>From: Kengo NAKAHARA
>
>I back to gif(4) MP-ify, since I could eliminate bottleneck of
>MP-scalable bridge(4) to support wm(4) TX multiqueue.
>
>I rebase my gif(
Hi,
On 2016/06/18 3:56, Taylor R Campbell wrote:
>Date: Fri, 17 Jun 2016 17:57:50 +0900
>From: Kengo NAKAHARA
>
>I have reconsidered and researched gif(4) implementation, as a result
>I think gif(4) Tx softint(9) should be eliminated. That is, the
>
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
Hi,
On 2016/06/16 15:49, Kengo NAKAHARA wrote:
> 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
>>
>>I rewrite my code. Here is patch seri
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
>
>I rewrite my code. Here is patch series,
>
> http://www.netbsd.org/~knakahara/separate-l3-lock-2/separate-l3-l
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
> snip
>>> That said, why not not us
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
snip
>> That said, why not not use two flags, say IFEF_OUTPUT_MPSAFE and
>> IFEF_START_MPSAFE? I ne
Hi,
On 2016/06/14 23:14, Taylor R Campbell wrote:
>Date: Tue, 14 Jun 2016 13:33:08 +0900
>From: Kengo NAKAHARA
>
>The design to implement this concept is consisted of below two parts.
>1. at L3 output processing call L2 output routine
> - remov
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
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
>
>I back to gif(4) MP-ify, since I could eliminate bottlenec
-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
>
>On 2016/04/27 0:27, Taylor R Campbell wrote:
>> - Why not call the struct ifnet member `if_enqueue'?
>>
>&g
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
>
>Does anyone have any comments or objections? If there is no objection,
>I will commit this patch after a few days or a few weeks.
>htt
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
>> i
? Any comments are welcome.
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
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 stru
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
>
>Sorry, I found one more question. _pslist_writer_next_container() does
>not use "next" variable. I think the fo
Hi,
On 2016/04/08 1:05, Taylor R Campbell wrote:
>Date: Thu, 7 Apr 2016 17:50:56 +0900
>From: Kengo NAKAHARA
>
>I have a question. It seems that pslist_writer_insert_after() does not
>change old entry->ple_next->ple_prevp. I think pslist_writer_insert_aft
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
>>
>>The attached pslist.h implements a pserialize-safe alternative to the
>>
be better for the function name.
For the rest, it looks good to me. I'm eager that it is committed.
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
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 ta
Hi,
On 2016/04/04 2:51, Taylor R Campbell wrote:
>Date: Fri, 1 Apr 2016 20:04:01 +0900
>From: Kengo NAKAHARA
>
>When I use the kernel built by "build.sh kernel=GENERIC" (the source is
>updated at March 31), I find dtrace(1) error which prints t
h
Could you comment 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
1 - 100 of 193 matches
Mail list logo