Re: RFC: new ifnet MP-scalable sending interface

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   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.