Re: A new network interface send queue API

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

> Date: Sat, 11 Nov 2023 15:20:56 -0800
> From: Jason Thorpe <thorpej%me.com@localhost>
> 
> To address the above problems, I'm proposing a new interface output
> queue API that tackles the above points while also being simple
> to adopt (with a reasonably straight-forward mapping from the legacy
> API to the new API).  Converting all drivers to this new API will
> be pretty easy and will help move the needle on the transition to a
> NET_MPSAFE world.

Cool, thanks for looking into this!  I've always found the API
contract for NIC drivers about packet queueing to be hard to follow,
and it will be great to clean it up.

Some questions that came up while I skimmed:

1. Does this affect the custom if_transmit path at all?

2. What's the impact on altq?

3. Can you draw a state transition diagram?  Just a summary that's a
   little easier to digest than the prose descriptions.

4. Can you show a complete working example of a driver conversion?
   (The examples you gave look good, but I don't see, e.g., anything
   that calls ifq_start.)  I guess this will be on the branch?

5. Will this eliminate all open-coded calls to struct ifnet::if_start
   and replace them by a wrapper function with a well-defined API
   contract?

6. Will this eliminate all access to ifp->if_flags & IFF_RUNNING in
   drivers' if_start routines?

7. Maybe ifq_restage should take the original mbuf as another argument
   to detect and assert no misuse?

8. Any impact on usbnet(4)?  (Guessing no, but maybe it will let us
   simplify usbnet(4) further?)

I probably won't have time to review the whole thing closely for a
while, but nothing jumped out at me as problematic, so don't take any
of my questions here as objections and don't let me get in the way of
working on this!