Re: RFC: new ifnet MP-scalable sending interface

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

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-nakahara%iij.ad.jp@localhost>
> 
>    On 2016/04/27 0:27, Taylor R Campbell wrote:
>    > - 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.
> 
> joerg's rationale is good enough for me.  if_transmit is fine.
> 
>    > - 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.
> 
> No, on reflection, I think using the member directly is probably fine.

Thank you for comments. I commit the patch.


Thanks,

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

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

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