Date: Wed, 27 Apr 2016 16:27:56 +0900 From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
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.