Re: RFC: new ifnet MP-scalable sending interface

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

On 2016/04/27 0:27, Taylor R Campbell wrote:
>    Date: Tue, 26 Apr 2016 13:22:40 +0900
>    From: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
> 
>    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.
>        http://www.netbsd.org/~knakahara/if-transmit/if-transmit.patch
>        # rebased, no functional changes
> 
> Two little suggestions:
> 
> - Why not call the struct ifnet member `if_enqueue'?
> 
> It may be confusing to add a new verb `transmit' to a lexicon that
> already has a lot of local jargon.

Fair enough. However "if_enqueue" would not be appropriate as joerg@n.o
point out in the other mail.
Hmm..., I think of the following candidates, but I cannot determine.
# As you know, I am not good at English...
    - if_express
    - if_post
    - if_pass
    - if_downward
    - if_direct
    - if_transmit (again)
    - if_enqueue (again)

Which one is better? Anything else better?


> - Have you considered making all callers use the ifq_enqueue function,
> instead of calling the if_transmit member directly?
> 
> Generally, I would like to see a clearer separation between
> (a) the responsibilities of a driver (`fill in ifp with functions
>   that implement your functionality'), and
> (b) the responsibilities of a caller in the network stack (`call
>   ifq_enqueue to send a packet off to the driver').
> But maybe in this case it doesn't matter so much, if there's no
> additional logic in ifq_enqueue.

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
like avoiding extra if-else statement in fast path every time. However,
as you point out, it would not be a clear responsibility separation...
Hmm, I will implement if_transmit to virtual interfaces such as gif(4).
Do you think virtual interfaces should also use ifq_enqueue? If so,
I will modify to use ifq_enqueue.


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>