pted. :)
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
nt.
Could you comment this implementation?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
Thank you for comments.
On 2015/04/09 19:44, Kengo NAKAHARA wrote:
> I implement x86 MD MSI/MSI-X support code. Here is the patch:
> http://www.netbsd.org/~knakahara/md-msi-msix/x86-md-msi-msix.patch
>
> Furthermore, here is the usage example of if_wm:
> http:/
Hi,
On 2015/04/16 11:49, Kengo NAKAHARA wrote:
> On 2015/04/09 19:44, Kengo NAKAHARA wrote:
>> I implement x86 MD MSI/MSI-X support code. Here is the patch:
>> http://www.netbsd.org/~knakahara/md-msi-msix/x86-md-msi-msix.patch
>>
>> Furthermore, here is the usage ex
in a few days.
Could you comment this modification?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi
On 2015/05/11 23:18, Christos Zoulas wrote:
> In article <555048fd.6020...@iij.ad.jp>,
> Kengo NAKAHARA wrote:
>> I received feedback from some device driver authors. They point out
>> establish, disestablish and release APIs should be unified for INTx,
>> MSI
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2015/05/13 10:34, Christos Zoulas wrote:
> On May 13, 9:03am, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: change MSI/MSI-X APIs
>
> | > http://www.netbsd.org/~christos/if_wm-example.diff
> | > [I have not even tried to compile thi
terrupt(s), to establish RX interrupt(s),
and to establish a link-state-changing interrupt.
# "WM_NINTR" must be gone and it is required to decide dynamically
# the number of using interrupts in the future.
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
vers which need pci_{intx,msi,msix}_alloc(),
# therefore other some drivers need pci_msix_alloc_map().
Could you comment about both whether above APIs match your suggestions
and any other pointing?
Thanks,
--
//////
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
Thank you for many suggestions!
On 2015/05/15 0:17, Christos Zoulas wrote:
> On May 14, 7:40pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: change MSI/MSI-X APIs
> Here's a slightly modified version that gets rid of the flags and simplifies
> the
Hi,
On 2015/05/13 1:40, Terry Moore wrote:
>> From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
>> Behalf Of Kengo NAKAHARA
>> On 2015/05/11 23:18, Christos Zoulas wrote:
>>> Can't we have a:
>>>
>>> int pci_intr_map
Hi,
I'm sorry for late reply.
On 2015/05/31 6:45, David Laight wrote:
> On Mon, May 11, 2015 at 03:15:25PM +0900, Kengo NAKAHARA wrote:
>> Hi,
>>
>> I received feedback from some device driver authors. They point out
>> establish, disestablish and release APIs sh
Hi,
On 2015/05/19 2:39, Terry Moore wrote:
>> -Original Message-
>> From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
>> Behalf Of Kengo NAKAHARA
>> Sent: Sunday, May 17, 2015 23:58
>> To: tech-kern@netbsd.org; t...@mcci.com
>> Cc
Hi,
I'm sorry for late reply, too.
On 2015/05/18 22:05, Christos Zoulas wrote:
> On May 18, 3:57pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: change MSI/MSI-X APIs
>
> | What do you think about below pci_intr_alloc() API?
> | http://mail-index.netbs
Hi,
On 2015/07/15 23:27, Christos Zoulas wrote:
> In article <55a63935.4010...@iij.ad.jp>,
> Kengo NAKAHARA wrote:
>
>> Thus, here is the implementation of above specification (include man)
>>http://netbsd.org/~knakahara/unify-alloc-api/unify-alloc-api.patch
&g
Hi,
On 2014/09/12 11:47, Kengo NAKAHARA wrote:
> (2014/08/20 18:06), Kengo NAKAHARA wrote:
>> I implement "intrctl" for amd64 and i386. Here is the implementation,
>> https://github.com/knakahara/netbsd-src/compare/rfc/irq-affinity2
>> and here is the patch
>
Hi,
On 2015/07/17 0:13, Christos Zoulas wrote:
> In article <55a72c01.2050...@iij.ad.jp>,
> Kengo NAKAHARA wrote:
>>
>> Thank you for your comment. I fix pci_intr_alloc() uses int *counts.
>> I also fix missing about man installation and some wording. He
Hi,
# Sorry, the mail I sent some hours ago is wrong...
# This is correct mail.
On 2015/07/17 0:13, Christos Zoulas wrote:> In article
<55a72c01.2050...@iij.ad.jp>,
> Kengo NAKAHARA wrote:
>>
>> Thank you for your comment. I fix pci_intr_alloc() uses int *counts.
>
Hi,
Thank you for your comments.
On 2015/07/17 5:18, Mindaugas Rasiukevicius wrote:
> Kengo NAKAHARA wrote:
>> There has been no objection for about 10 months...
>> So, I am going to commit this implementation. Here is the rebased
>> patch,
>> http://ne
Hi,
On 2015/07/23 19:44, Kengo NAKAHARA wrote:
> Hi,
>
> Thank you for your comments.
>
> On 2015/07/17 5:18, Mindaugas Rasiukevicius wrote:
>> Kengo NAKAHARA wrote:
>>> There has been no objection for about 10 months...
>>> So, I am going to commit t
tag_t instead of pci_attach_args.
Why pci_msi{,}_count() use pci_attach_args at present? It is my
mistake, sorry...
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2015/08/11 10:59, Kengo NAKAHARA wrote:
> Hi,
>
> On 2015/07/23 19:44, Kengo NAKAHARA wrote:
>> Hi,
>>
>> Thank you for your comments.
>>
>> On 2015/07/17 5:18, Mindaugas Rasiukevicius wrote:
>>> Kengo NAKAHARA wrote:
>>>> Ther
evelopment Department,
Product Division,
Technology Unit
Kengo NAKAHARA
///
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2015/12/18 14:07, Thor Lancelot Simon wrote:
> On Fri, Dec 18, 2015 at 11:09:17AM +0900, Kengo NAKAHARA wrote:
>>
>> I think softint_disestablish should wait not only SOFTINT_ACTIVE
>> but also SOFTINT_PENDING flag, that is, the following patch is
>
Hi,
On 2015/12/21 11:42, Kengo NAKAHARA wrote:
> On 2015/12/18 14:07, Thor Lancelot Simon wrote:
>> On Fri, Dec 18, 2015 at 11:09:17AM +0900, Kengo NAKAHARA wrote:
>>>
>>> I think softint_disestablish should wait not only SOFTINT_ACTIVE
>>> but also SOFTINT_
Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi christos@n.o,
Thank you for review and comments.
On 2015/12/26 1:11, Christos Zoulas wrote:
> In article <567d031f.90...@iij.ad.jp>,
> Kengo NAKAHARA wrote:
>> I MP-ify gif(4) interface and ip_encap which is required by gif(4).
>>
>> Here is the patch
>>
Hi riastradh@n.o,
On 2015/12/26 23:47, Taylor R Campbell wrote:
>Date: Fri, 25 Dec 2015 17:49:35 +0900
>From: Kengo NAKAHARA
>
>I MP-ify gif(4) interface and ip_encap which is required by gif(4).
>
>Here is the patch
>http://www.netbsd.org/~knakah
Hi,
Thank you for comments. I update the patch.
On 2015/12/25 17:49, Kengo NAKAHARA wrote:
> I MP-ify gif(4) interface and ip_encap which is required by gif(4).
>
> Here is the patch
> http://www.netbsd.org/~knakahara/gif-mp-ify/gif-mp-ify.patch
Here is the updated patch
Hi,
On 2016/01/06 3:40, Taylor R Campbell wrote:
>Date: Tue, 5 Jan 2016 17:30:35 +0900
>From: Kengo NAKAHARA
>
>I use rw_init() for gif_softc_list_lock instead of rw_obj_alloc().
>However, I still use rw_obj_alloc() for struct gif_softc.gif_lock.
>If I
Hi,
On 2016/01/07 0:26, Taylor R Campbell wrote:
>Date: Wed, 6 Jan 2016 14:19:01 +0900
>From: Kengo NAKAHARA
>
>I have a question for confirmation. If the struct has two locks for
>different purposes, is the COHERENCY_UNIT padding required between
>the l
ld you comment this patch?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
+
+#include "opt_multiprocessor.h"
+
+#include
+
+#ifdef MULTIPROCESSOR
+__cpu_simple_lock_t __mcount_lock;
+#endif
Could you comment this patch? Any comments are welcome.
Thanks,
--
//////
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
to common/lib/libc/gmon/mcount.c
> from machine/profile.h as below.
Thank you for your more appropriate fix and commit.
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
Thank you for your closeup review!
On 2016/01/11 14:48, Taylor R Campbell wrote:
>Date: Wed, 6 Jan 2016 14:19:01 +0900
>From: Kengo NAKAHARA
>
>On 2016/01/06 3:40, Taylor R Campbell wrote:
>> There are a couple other things I'm concerned
Hi,
On 2016/01/13 4:19, Taylor R Campbell wrote:
>Date: Fri, 18 Dec 2015 11:09:17 +0900
>From: Kengo NAKAHARA
>
>I think softint_disestablish should wait not only SOFTINT_ACTIVE
>but also SOFTINT_PENDING flag, that is, the following patch is
>required
>
Hi,
On 2016/01/13 4:38, Taylor R Campbell wrote:
>Date: Tue, 12 Jan 2016 18:54:44 +0900
>From: Kengo NAKAHARA
>
>Yes, I removed atomic operations from gif(4) packet-processing path,
>as note above. I think the fix for PR/50522 fixes the race between
>
Hi,
On 2016/01/12 18:54, Kengo NAKAHARA wrote:
> On 2016/01/11 14:48, Taylor R Campbell wrote:
>> I think the following protocol should be simpler and safer:
>>
>> - One global interruptible lock for the system's gif(4) configuration.
>> - No per-gif(4) locks at
Hi, riastradh@n.o
Thank you for comments.
On 2016/01/23 1:29, Taylor R Campbell wrote:
>Date: Fri, 22 Jan 2016 13:37:23 +0900
>From: Kengo NAKAHARA
>
>I implement this processing. Here is the patch.
>http://netbsd.org/~knakahara/fix-gif-softint/fix-gi
//
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
////////
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2016/02/10 1:07, Taylor R Campbell wrote:
>Date: Tue, 9 Feb 2016 20:33:51 +0900
>From: Kengo NAKAHARA
>
>Is "target->prt_draining = false;" required at the end of
> psref_target_drain()?
>Or, shouldn't psref_target_drain() be called tw
Hi riastradh@n.o
On 2016/02/11 3:01, Taylor R Campbell wrote:
>Date: Wed, 10 Feb 2016 17:20:15 +0900
>From: Kengo NAKAHARA
>
>I tried to use passive reference for a encaptab list itself instead of
>pserialize_read_enter().
># As you know, packet processing
class;
> pserialize_tpsz;
> } encaptab __cacheline_aligned;
>
> Then `encaptab_struct.ets_list' becomes a little less of a mouthful,
> just `encaptab.list'. We have some other examples of this pattern in
> src, such as vcache in sys/kern/vfs_vnode.c.
I see, I apply this way.
Could you comment the above patch?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2016/02/16 7:23, Taylor R Campbell wrote:
>Date: Mon, 15 Feb 2016 19:26:44 +0900
>From: Kengo NAKAHARA
>
>First, I fix some bug which you point out. Here is the
>"git format-patch" patch series.
>
> http://www.netbsd.org/~knakahara/f
c.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2016/02/19 19:01, Thomas Klausner wrote:
> On Fri, Feb 19, 2016 at 06:26:14PM +0900, Kengo NAKAHARA wrote:
>> According to my measurements of using DTrace, there is a certain
>> overhead between kern_malloc() and pool_cache_get(). Here is each
>> function's aver
Hi,
On 2016/02/19 19:05, Roy Marples wrote:
> On 19/02/2016 09:26, Kengo NAKAHARA wrote:
>> According to my measurements of using DTrace, there is a certain
>> overhead between kern_malloc() and pool_cache_get(). Here is each
>> function's average turnarou
Hi,
On 2016/02/19 19:38, Joerg Sonnenberger wrote:
> On Fri, Feb 19, 2016 at 06:26:14PM +0900, Kengo NAKAHARA wrote:
>> Of course, m_tag_get() is used by packet processing path, this overhead
>> would have a certain influence on packet throughput and latency.
>> So, I thi
nk
OpenBSD can be helpful. OpenBSD does not have ip_encap, however implement
gif and mroute.
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
Hi,
On 2016/02/19 21:25, Joerg Sonnenberger wrote:
> On Fri, Feb 19, 2016 at 08:29:35PM +0900, Kengo NAKAHARA wrote:
>> I agree it should be removed in first place. However, I think there is
>> several cases which cannot avoid to use m_tag. So, it may be required
>> to rescu
ernet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA
unnecessary.
http://www.netbsd.org/~knakahara/fix-gif-softint-using-psref2/unified-fix-gif-softint-using-psref2-2.patch
On 2016/03/01 3:07, Taylor R Campbell wrote:
>Date: Wed, 17 Feb 2016 13:56:02 +0900
>From: Kengo NAKAHARA
>
>I fix above bugs and rebase, here is "git fo
Hi,
On 2016/02/23 13:52, Kengo NAKAHARA wrote:
> I want to uniform IFQ_ENQUEUE arguments whether ALTQ is defined or not.
> # And I also want to eliminate ALTQ_DECL and ALTQ_COMMA macros...
> So, I make struct altq_pktattr from IFQ_CLASSIFY and IFQ_ENQUEUE argument
> to m_tag. Here
Hi,
Thank you for comments.
On 2016/03/04 12:23, Taylor R Campbell wrote:
>Date: Fri, 4 Mar 2016 12:01:52 +0900
>From: Kengo NAKAHARA
>
>On 2016/02/23 13:52, Kengo NAKAHARA wrote:
>> I want to uniform IFQ_ENQUEUE arguments whether ALTQ is defined or not.
&
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 or not.
>> # And I also want to eliminate ALTQ_DECL and ALTQ_COMMA macr
Hi,
On 2016/03/08 1:26, Taylor R Campbell wrote:
>Date: Mon, 7 Mar 2016 17:39:15 +0900
>From: Kengo NAKAHARA
>Hmm..., sorry, I am confused. Just to confirm, m_tag needs metadata
>(struct m_tag) in the front of m_tag data(e.g. in this case struct
>altq_pktqttr),
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
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
>
>I rebase and modify a little(use container_of). Here is the patch.
>
> http://www.netbsd.org/~knakahara/ifq-enqueue-re
ment this patch?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
ppropriate or not, but I have
no idea to fix this 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
ry to have no
enough time to fix it appropriately. I just want to let some headers
include sys/sdt.h and compile GENERIC kernel...
So, I just add SDT_PROVIER_DEFINE(sdt) to help Someone's future works.
Thanks,
--
//
Inter
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
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
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/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 *.
>>
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/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
>>
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,
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/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,
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,
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/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.
>>>
? 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/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
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/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 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, 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
-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,
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
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
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
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/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,
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 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
k Division,
Technology Unit
Kengo NAKAHARA
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
>>
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/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/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(
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network 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
twork Division,
Technology Unit
Kengo NAKAHARA
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
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
1 - 100 of 193 matches
Mail list logo
